Transfer-Encoding: gzip vs. Content-Encoding: gzip

Jaki jest obecny stan rzeczy, jeśli chodzi o to, czy zrobić

Transfer-Encoding: gzip

Lub

Content-Encoding: gzip

Kiedy chcę zezwolić klientom z np. ograniczoną przepustowością do zasygnalizować chęć zaakceptowania skompresowanej odpowiedzi, A Serwer ma ostatnie słowo, czy kompresować.

Ten ostatni jest tym, co robią np. mod_deflate Apache i IIS, jeśli pozwolisz, aby zajął się kompresją. W zależności od wielkości zawartość, która ma być skompresowana, wykona dodatkowe Transfer-Encoding: chunked.

Będzie również zawierać Vary: Accept-Encoding, który już podpowiada problem. Content-Encoding wydaje się być częścią encji, więc zmiana Content-Encoding oznacza zmianę encji, tzn. inny nagłówek Accept-Encoding oznacza, że np. cache nie może używać swojej buforowanej wersji identycznej encji.

Czy jest na to konkretna odpowiedź, którą przeoczyłem (i to nie jest zakopane w wiadomości w długim wątku w jakimś apache grupa dyskusyjna)?

Moje obecne wrażenie to:

W rzeczywistości kodowanie transferowe byłoby właściwym sposobem na to, co najczęściej robi się z kodowaniem treści za pomocą istniejących implantów serwera i klienta.]}
• kodowanie treści, ze względu na swoje semantyczne implikacje, niesie ze sobą kilka problemów (co serwer powinien zrobić z ETag, gdy transparentnie kompresuje odpowiedź?)
• powodem jest chicken ' n ' Egg: przeglądarki nie obsługują tego, ponieważ serwery nie obsługują, ponieważ przeglądarki nie

Więc zakładam, że właściwą drogą będzie Transfer-Encoding: gzip (lub, jeśli dodatkowo pochłonie ciało, to stanie się Transfer-Encoding: gzip, chunked). I nie ma powodu dotykać Vary lub ETag lub jakiegokolwiek innego nagłówka w tym przypadku, ponieważ jest to rzecz na poziomie transportu.

Na razie nie dbam zbytnio o "hop-by-hop" - ness Transfer-Encoding, coś, o co inni wydają się martwić przede wszystkim, ponieważ proxy mogą dekompresować i przesyłać nieskompresowane do klienta. Jednak proxy może równie dobrze przesłać je tak, jak-jest (skompresowane), jeśli oryginalne żądanie ma właściwy nagłówek Accept-Encoding, który w przypadku wszystkich przeglądarek, które znam, jest dany.

Btw, ten problem ma co najmniej dekadę, patrz np. https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Wszelkie wyjaśnienia na ten temat będą mile widziane. Zarówno pod względem tego, co jest uważane za zgodne z normami, jak i tego, co jest uważane za praktyczne. Na przykład biblioteki klientów HTTP obsługujące tylko przezroczyste "Kodowanie treści" byłoby argumentem przeciwko praktyczności.