The connection opens. Request headers leave. The file appears not to move. One explanation is that the client is waiting for a response to Expect: 100-continue before transmitting its body.

The mechanism lets a recipient reject a request from its headers before a potentially large upload is sent. The ordinary successful sequence is:

request headers → 100 Continue → request body → final response

100 is informational: it allows the client to proceed, but does not mean the file has been stored or the application operation has succeeded. A Git push returning HTTP 417 is one concrete expectation-failure case.

Find which response the client received

ObservationMeaning to investigate
100 ContinueThe client can proceed with the body
A final rejection before the bodyThe operation was refused at the header stage
No expected interim responseThe client's waiting policy and the handling on that path

curl exposes a dedicated expect-continue wait setting. If that libcurl wait expires without the expected response, it sends the body anyway; expiry is not automatically a failed whole transfer. The setting is separate from the time allowed for the complete transfer. Increasing the latter can leave the same initial pause unexplained.

Also identify which HTTP conversation carries Expect. With ordinary CONNECT to an HTTPS destination, the website's upload exchange is inside TLS; the forward proxy does not simply inspect its inner expectation header. An interception or plaintext forwarding path is different.

Removing the expectation can be a deliberate compatibility choice, but it means the client may start sending a large body before learning about an early rejection. Compare that behavior with the actual requirement. Do not describe a historical workaround for an old proxy as a universal instruction to strip the header from every upload.

Аффингæй хæстæг статьялтæ