Content-Length는 메시지 본문의 전송 길이를 설명하는 데 사용됩니다. HTTP 프로토콜에서는 메시지 엔티티의 길이와 메시지 엔티티의 전송 길이 사이에 차이가 있습니다. 예를 들어, gzip 압축 하에서는 메시지 엔티티의 길이가 압축 전의 길이이고, 메시지 엔티티의 전송 길이는 gzip 압축 이후의 길이입니다.
특정 HTTP 상호작용에서 클라이언트가 메시지 길이를 얻는 방법은 주로 다음 규칙에 기반합니다:
응답이 1xx, 204, 304 또는 헤드 요청이라면, 메시지 엔터티 내용은 직접 무시됩니다.
전송-인코딩이 존재한다면, 해당 길이를 찾는 데 선호되는 방법이 전송-인코딩 방식입니다. 예를 들어, 청크드 모델이 있습니다.
"머리에 내용 길이가 있다면, 이 내용 길이는 신체 길이와 전달 길이를 모두 나타냅니다. 엔터티 길이와 전송 길이가 같지 않으면(예: 전송-인코딩이 설정되어 있다면), Content-Length를 설정할 수 없습니다.전송-인코딩이 설정되어 있으면 Content-Length는 무시됩니다”。 이 문장 번역의 장점은 단 하나의 점만 존재한다는 점입니다: 전송-인코딩에서는 Content-Length가 존재할 수 없습니다.
거리 전송. 저는 주의를 기울이지 않았고, 자세히 읽지도 않았습니다:)
서버를 통한 연결을 닫으면 전송되는 메시지의 길이가 결정됩니다. (요청자는 연결을 닫아서 요청 본문의 끝을 표시할 수 없는데, 이는 서버가 계속 응답할 기회를 잃게 되기 때문입니다.) 이 상황은 주로 짧은 연결, 즉 생존 유지가 아닌 모드에 해당합니다.
HTTP 1.1은 청크 모드를 반드시 지원해야 합니다. 메시지 길이가 불확실할 때는 청크 메커니즘을 통해 이 상황을 처리할 수 있기 때문입니다.
메시지 내용이 포함된 헤더에서 content-length 필드가 있다면, 해당 필드의 값이 메시지 주제의 길이와 정확히 일치해야 합니다.
"메시지의 엔터티 길이는 전송 코딩이 적용되기 전의 메시지 본체 길이입니다"
말하자면청크가 존재한다면, 내용 길이가 존재할 수 없습니다 。
HTTP/1.0의 지속적 연결 메커니즘은 나중에 도입되었으며, 이는 Connection: keep-alive 헤더를 통해 구현되어 서버와 클라이언트 모두 데이터를 전송한 후 TCP 연결을 끊을 필요가 없음을 상호 알릴 수 있습니다.HTTP/1.1은 모든 연결이 영구적이어야 함을 요구합니다，헤더 근처에 명시적으로 Connection: 항목을 추가하지 않는 한。 따라서 실제로 HTTP/1.1의 Connection 헤더 필드는 더 이상 keep-alive 값을 가지지 않지만, 역사적 이유로 많은 웹 서버와 브라우저가 여전히 HTTP/1.1 긴 연결에 Connection: keep-alive 전송 방식을 유지하고 있습니다.
사실 마지막 몇 가지는 거의 무시해도 되고, 간략한 요약은 다음과 같습니다:
1. 내용 길이: 만약 존재하고 유효하다면, 메시지 내용의 전송 시간과 정확히 동일해야 합니다. (너무 짧으면 잘라내도록 테스트했고, 타임아웃이 생기기에는 너무 길어질 경우 검사했습니다.) ）
2. 전송-인코딩(Transfer-Encoding)이 존재하는 경우(포커스가 청크되어 있음), 헤더에 Content-Length가 없으면 무시됩니다.
3. 짧은 연결을 사용할 경우, 서버를 통해 연결을 종료하여 메시지 전송 시간을 직접 결정할 수 있습니다. (이해하기 쉽습니다)
HTTP 프로토콜의 다른 기능과 결합해 Http1.1은 Keep alive를 지원하지 않았습니다. 따라서 다음과 같은 결론을 도출할 수 있습니다:
1. Http 1.0 및 이전 버전에서는 content-length 필드가 선택 사항입니다.
2. http1.1 및 이후 버전에서. 살아남는다면, 콘텐츠 길이와 청크는 둘 중 하나여야 합니다. 만약 유지되지 않으면 http1.0과 동일합니다. 내용 길이.
|
게시됨 2019. 9. 24. 오후 3:53:29
|
|
|
