Re: "always" parameter in "gzip_static" directive

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Sep 12, 2012 at 03:58:52PM +0300, Gena Makhomed wrote:

> On 10.09.2012 19:48, in nginx-devel Maxim Dounin wrote:
> 
> > Gzip static: "always" parameter in "gzip_static" directive.
> > With "always" gzip static returns gzipped content in all cases,
> > without checking if client supports it.
> > It is useful if there are no uncompressed files on disk anyway.
> 
> если клиент говорит что не понимает compressed ответы
> и на диске нет uncompressed files - почему в этом случае
> нельзя отдать uncompressed ответ, пропустив compressed files
> перед отдачей клиенту через ngx_http_gunzip_filter_module ?

Можно - для этого достаточно включить gunzip.  Делать подобное 
включение автоматическим - это, с моей точки зрения, типичный 
случай layering violation.

> так было бы более корректно с точки зрения RFC, (?)
> потому что обычно, если клиент говорит что не понимает
> compressed ответ - он его действительно не понимает...
> 
> тогда вообще не надо было бы добавлять новый параметр "always"
> к директиве "gzip_static" и nginx всегда работал бы корректно.

С точки зрения RFC - заголовок Content-Encoding говорит о 
encoding'е возвращаемого документа (entity).  Возврат разных 
документов (с разным encoding'ом) в зависимости от того, что 
клиент указывает в заголовке Accept-Encoding, суть один из 
возможных вариантов реакции на предпочтения клиентов.  Если других 
вариатов документа нет - никто не машет вернуть документ в том 
виде, в котором есть.

Часто встречающимся примером аналогичного поведения является 
возврат документа на том языке, на котором он есть, без перевода 
на один из языков, указанных клиентом в заголовке Accept-Language.  
Или возврат документов в том формате (и с тем Content-Type), в 
котором они лежат на сервер, вне зависимости от полученного от 
клиента заголовка Accept.

Подробнее о всём этом с точки зрения RFC можно прочитать 
собственно в самом RFC 2616:

http://tools.ietf.org/html/rfc2616#section-12

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru