[http] 전송 인코딩 : gzip 대 콘텐츠 인코딩 : gzip

Program / 글쓴이

수행 여부와 관련하여 현재 상황은 무엇입니까?

Transfer-Encoding: gzip

또는

Content-Encoding: gzip

내가 허용 할 때 클라이언트 예를 들어 제한된 대역폭가 수용 할 의지 신호를 압축 응답 과 서버가 있는지 여부 압축에 마지막 말을 .

후자는 예를 들어 Apache의 mod_deflate 및 IIS가 수행하는 작업입니다. 압축 할 콘텐츠의 크기에 따라 추가 작업을 수행합니다.Transfer-Encoding: chunked .

또한 Vary: Accept-Encoding이미 문제를 암시하는를 포함합니다 . Content-Encoding엔티티의 일부인 것처럼 보이므로 Content-Encoding금액을 엔티티의 변경, 즉 다른Accept-Encoding 헤더는 예를 들어 캐시가 다른 동일한 엔티티의 캐시 된 버전을 사용할 수 없음을 의미합니다.

내가 놓친 확실한 대답이 있습니까 (그리고 일부 아파치 뉴스 그룹의 긴 스레드에 메시지 안에 묻혀 있지 않습니다)?

나의 현재 인상은 :

  • 실제로 Transfer-Encoding은 기존 서버 및 클라이언트 구현에 의해 대부분 Content-Encoding으로 수행되는 작업을 수행하는 올바른 방법입니다.
  • Content-Encoding은 의미 론적 의미로 인해 몇 가지 문제가 있습니다 (서버가 ETag응답을 투명하게 압축 할 때 어떻게해야 합니까?).
  • 그 이유는 chicken’n’egg입니다 : 브라우저가 지원하지 않기 때문에 서버가 지원하지 않기 때문에 브라우저가 지원하지 않습니다.

내가 올바른 방법을 가정하고 그래서 일 것이다 Transfer-Encoding: gzip(I 추가 덩어리 몸,이 경우, 또는 이 될 것이다 Transfer-Encoding: gzip, chunked ). 그리고 이유는 만지지에 Vary나ETag 그것이 전송 수준 일이 그 경우에 다른 헤더 나.

지금은 Transfer-Encoding프록시가 압축을 풀고 압축되지 않은 상태로 클라이언트에 전달할 수 있기 때문에 다른 사람들이 가장 먼저 염려하는 것처럼 보이는 ‘hop-by-hop’성에 대해별로 신경 쓰지 않습니다 . 그러나 원래 요청에 적절한 Accept-Encoding헤더 가있는 경우 프록시는 그대로 (압축) 전달할 수 있으며 , 이는 내가 아는 모든 브라우저의 경우 주어진 것입니다.

Btw,이 문제는 적어도 10 년이 지난 것 입니다. 예를 들어 https://bugzilla.mozilla.org/show_bug.cgi?id=68517을 참조
하십시오 .

이에 대한 설명을 주시면 감사하겠습니다. 표준을 준수하는 것으로 간주되는 것과 실용적인 것으로 간주되는 것 모두에서. 예를 들어, 투명한 “Content-Encoding”만 지원하는 HTTP 클라이언트 라이브러리는 실용성에 대한 논쟁이 될 수 있습니다.

답변

RFC 2616의 저자 중 한 명인 Roy T. Fielding을 인용합니다 .

일관성없는 방식 ( “절대”도 “항상”도 아님)으로 즉석에서 컨텐츠 인코딩을 변경하면 해당 컨텐츠 (예 : PUT 또는 조건부 GET)에 대한 이후 요청을 올바르게 처리 할 수 ​​없습니다. 물론 이것이 수행하는 이유입니다. on-the-fly 콘텐츠 인코딩은 어리석은 생각이며, 리소스를 변경하지 않고 on-the-fly 인코딩을 수행하는 적절한 방법으로 HTTP에 Transfer-Encoding을 추가 한 이유입니다.

출처 : https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

즉 , 즉석에서 콘텐츠 인코딩을하지 말고 대신 전송 인코딩을 사용하십시오!

편집 : 즉, Content-Encoding 만 이해하는 클라이언트에게 gzip으로 압축 된 콘텐츠를 제공하지 않으려 는 경우 입니다. 불행히도 대부분의 것 같습니다. 그러나 사양의 영역 을 벗어나면 Fielding 및 기타에서 언급 한 문제 (예 : 캐싱 프록시가 관련 될 때)와 같은 문제가 발생할 수 있습니다.

답변

올바른 사용, 같은 RFC 2616에 정의되어 실제로 야생에서 구현은, 보낼 수있는 클라이언트입니다 Accept-Encoding요청 헤더를 (클라이언트가 여러 인코딩을 지정할 수 있습니다). 그런 다음 서버는 클라이언트가 지원하는 인코딩에 따라 응답을 인코딩 할 수 있습니다 (파일 데이터가 해당 인코딩에 아직 저장되지 않은 경우). Content-Encoding응답 헤더에 사용중인 인코딩을 표시 할 수 있습니다. 클라이언트는 다음을 기반으로 소켓 오프 데이터를 읽을 수 있습니다 Transfer-Encoding(즉, chunked) 다음에 따라이를 디코딩 Content-Encoding(예 : gzip).

따라서 귀하의 경우 클라이언트는 Accept-Encoding: gzip요청 헤더를 보낸 다음 서버는 압축 (아직없는 경우)을 결정 Content-Encoding: gzip하고 선택적으로 Transfer-Encoding: chunked응답 헤더를 보낼 수 있습니다.

그리고 예, Transfer-Encoding헤더는 요청에 사용할 수 있지만 HTTP 1.1에서만 사용할 수 있습니다.이 경우 클라이언트와 서버 구현 chunked모두 양방향으로 인코딩을 지원해야합니다 .

ETag실제로 전송되는 데이터가 아니라 서버의 리소스 데이터를 고유하게 식별합니다. 주어진 URL 리소스가 해당 ETag값을 변경하면 해당 리소스에 대한 서버 측 데이터가 변경되었음을 의미합니다.

답변