Welcome! Log In Create A New Profile

Advanced

Re: Документация к директиве fastcgi_cache_key

Илья Шипицин
November 30, 2018 05:38AM
протоколы действительно разные.
но выглядит так, что предложение Гены поможет написать документацию, более
устойчивую к тупому копипасту (есть такой патерн, что глядя на пример
документации на авторитетном сайте, его копируют)

пт, 30 нояб. 2018 г. в 14:30, Gena Makhomed <gmm@csdoc.com>:

> On 29.11.2018 21:02, Maxim Dounin wrote:
>
> > CGI и HTTP - это два разных протокола. В последних вариациях на
> > тему спецификации CGI записано, что на HEAD-запросы тело
> > возвращать не надо (а если вдруг вернули - то сервер его должен
> > поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3:
> >
> > The HEAD method requests the script to do sufficient processing to
> > return the response header fields, without providing a response
> > message-body. The script MUST NOT provide a response message-body
> > for a HEAD request. If it does, then the server MUST discard the
> > message-body when reading the response from the script.
> >
> > Однако на момент собственно появления и активного распространения
> > CGI никаких подобных требований не существовало, см.
> > https://www.w3.org/CGI/ и в частности
> > https://tools.ietf.org/html/draft-robinson-www-interface-00.
>
> Там написано:
>
> REQUEST_METHOD
>
> This variable is specific to requests made with HTTP.
>
> The method with which the request was made, as described in
> section 5.1.1 of the HTTP/1.0 specification [3].
>
> http-method = "GET" | "HEAD" | "POST" | extension-method
>
> "described in HTTP/1.0 specification" - написано где смотреть семантику.
> А в HTTP/1.0 specification написано, что "server must not return any
> Entity-Body in the response".
>
> CGI и HTTP - это два разных протокола, но первый ссылается на второй.
> При этом CGI протокол не запрещает бекенду отвечать на HEAD-запросы
> так, как этого требует от веб-сервера спецификация HTTP протокола.
>
> > И на
> > практике я не встречал скрипты, которые бы отдельно обрабатывали
> > HEAD-запросы.
>
> Но они есть.
> И их поведение ничем не противоречит спецификации FastCGI протокола.
>
> >>> Речь про какие-то фреймворки, которые обрабатывают
> >>> HEAD автоматически, не донося соответствующую информацию до кода?
> >>> Или про какой-то стандартный софт, который не возвращает тело для
> >>> HEAD-запросов?
> >>
> >> Какая разница, сам софт или фрейморк используемый софтом в каждом
> >> конкретном случае обрабатывает HEAD запросы согласно требований RFC?
> >
> > Никакой. Но с этой точки зрения так же нет разницы, что именно
> > написано в примерах в описании директивы fastcgi_cache_key.
>
> Вы не против, если я создам на хабре статью, в которой напишу
> про эту проблему с ошибочными примерами в документации nginx
> к директиве fastcgi_cache_key и ее аналогам?
>
> --
> Best regards,
> Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Subject Author Posted

Документация к директиве fastcgi_cache_key

Gena Makhomed November 29, 2018 10:00AM

Re: Документация к директиве fastcgi_cache_key

Maxim Dounin November 29, 2018 11:32AM

Re: Документация к директиве fastcgi_cache_key

Gena Makhomed November 29, 2018 01:36PM

Re: Документация к директиве fastcgi_cache_key

Maxim Dounin November 29, 2018 02:04PM

Re: Документация к директиве fastcgi_cache_key

Gena Makhomed November 30, 2018 04:32AM

Re: Документация к директиве fastcgi_cache_key

Илья Шипицин November 30, 2018 05:38AM

Re: Документация к директиве fastcgi_cache_key

Константин Ткаченко December 03, 2018 04:04AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 101
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready