Jaki jest obecny stan rzeczy, jeśli chodzi o podjęcie decyzji
Transfer-Encoding: gzip
lub a
Content-Encoding: gzip
kiedy chcę pozwolić klientom z np. ograniczoną przepustowością na zasygnalizowanie swojej chęci przyjęcia skompresowanej odpowiedzi a serwer ma ostateczną decyzję, czy kompresować czy nie .
To ostatnie jest tym, co robią np. Mod_deflate Apache i IIS, jeśli pozwolisz mu zająć się kompresją. W zależności od rozmiaru zawartości do skompresowania, zrobi to dodatkowe Transfer-Encoding: chunked.
Będzie również zawierać Vary: Accept-Encodingpodpowiedź, która już wskazuje na problem. Content-Encodingwydaje się być częścią jednostki, więc zmianaContent-Encoding kwot w celu zmiany jednostki, tj. inny Accept-Encodingnagłówek oznacza, że np. pamięć podręczna nie może używać swojej buforowanej wersji identycznej jednostki.
Czy jest jakaś konkretna odpowiedź na to pytanie, którą przegapiłem (i nie jest ona ukryta w wiadomości w długim wątku w jakiejś grupie dyskusyjnej apache)?
Moje obecne wrażenie to:
- Transfer-Encoding byłby w rzeczywistości właściwym sposobem na zrobienie tego, co jest najczęściej robione z Content-Encoding przez istniejące implikacje serwera i klienta
- Content-Encoding, ze względu na swoje implikacje semantyczne, niesie ze sobą kilka problemów (co powinien zrobić serwer,
ETaggdy w przejrzysty sposób kompresuje odpowiedź?) - Powód jest taki, że chicken'n'egg: przeglądarki tego nie obsługują, ponieważ serwery nie obsługują, ponieważ przeglądarki nie obsługują
Zakładam więc, że właściwą drogą będzie Transfer-Encoding: gzip(lub, jeśli dodatkowo rozbiję ciało, stanie się Transfer-Encoding: gzip, chunked ). I nie ma powodu, by dotykać VarylubETag żadnego innego nagłówka w tym przypadku, ponieważ jest to rzecz na poziomie transportu.
Na razie nie obchodzi mnie zbytnio „przeskok po skoku” Transfer-Encoding, coś, czym inni wydają się być zainteresowani przede wszystkim, ponieważ serwery proxy mogą zdekompresować i przekazać klientowi bez kompresji. Jednak serwery proxy mogą równie dobrze przekazywać je w stanie, w jakim są (skompresowane), jeśli oryginalne żądanie ma odpowiedni Accept-Encodingnagłówek, który w przypadku wszystkich przeglądarek, które znam, jest dany.
Przy okazji, ten problem ma co najmniej dekadę, patrz np . Https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .
Wszelkie wyjaśnienia w tej sprawie 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 klienta HTTP obsługujące tylko przezroczyste „kodowanie zawartości” byłyby argumentem przeciwko praktyczności.