HTTP 업로드 일시 정지와 Expect: 100-continue
Expect: 100-continue 교환을 알아보고, 그 짧은 결정 지점과 데이터 전송 중 멈춘 업로드를 구분합니다.
연결이 열립니다. 요청 헤더가 나갑니다. 파일이 움직이지 않는 것처럼 보입니다. 한 가지 설명은 클라이언트가 본문을 보내기 전에 Expect: 100-continue 에 대한 응답을 기다리고 있다는 것입니다.
이 메커니즘은 수신자가 잠재적으로 큰 업로드가 전송되기 전에 헤더만으로 요청을 거부할 수 있게 합니다. 일반적인 성공 순서는 다음과 같습니다.
request headers → 100 Continue → request body → final response100은 정보성입니다. 클라이언트가 계속 진행하도록 허용하지만, 파일이 저장되었거나 애플리케이션 작업이 성공했다는 뜻은 아닙니다. HTTP 417 을 반환하는 Git push는 기대 실패의 구체적인 사례 하나입니다.
클라이언트가 어떤 응답을 받았는지 확인
| 관찰 | 조사할 의미 |
|---|---|
| 100 Continue | 클라이언트가 본문과 함께 진행할 수 있음 |
| 본문 전의 최종 거부 | 헤더 단계에서 작업이 거부됨 |
| 기대한 중간 응답이 없음 | 클라이언트의 대기 정책과 해당 경로의 처리 |
curl은 expect-continue를 위한 전용 대기 설정을 제공합니다. 그 libcurl 대기가 기대한 응답 없이 만료되면 본문을 그래도 보냅니다. 만료가 전체 전송 실패를 자동으로 의미하지는 않습니다. 이 설정은 전체 전송에 허용된 시간과 별개입니다. 후자를 늘려도 같은 초기 멈춤은 설명되지 않을 수 있습니다.
어떤 HTTP 대화가 Expect를 나르는지도 확인하십시오. HTTPS 대상에 대한 일반 CONNECT에서는 웹 사이트의 업로드 교환이 TLS 안에 있습니다. 포워드 프록시가 그 내부 기대 헤더를 그냥 검사하지는 않습니다. 가로채기나 평문 전달 경로는 다릅니다.
기대를 제거하는 것은 의도적인 호환성 선택일 수 있지만, 그 경우 클라이언트가 조기 거부를 알기 전에 큰 본문을 보내기 시작할 수 있습니다. 그 동작을 실제 요구 사항과 비교하십시오. 오래된 프록시를 위한 과거의 우회책을 모든 업로드에서 헤더를 제거하라는 보편적 지침으로 설명하지 마십시오.