Re: как работает gzip_static?

2020-05-03 Пенетрантность sergio
On 04/05/2020 00:13, Maxim Dounin wrote:

> Если вы и в этом случае видите ответ 404, 
> то это означает, что до gzip_static дело не доходит, и ответ 404 
> отправляется раньше.

> Например, так может быть, если у вас в конфиге стоит что-нибудь 
> вроде "try_files $uri =404;", то есть существование конкретного 
> файла проверяется явно.

Все так (:


Тогда следующий вопрос:

На диске лежит index.html.gz (index.html нет)
Запрос https://website.tld/index.html удачно отображается в браузере.
Запрашиваем https://website.tld/

Если написать "index index.html;" то nginx пытается отобразить
содержимое директории.

Если написать "index index.html.gz;" или "index index.html; try_files
$uri.gz =404;" или то nginx отдаёт index.html.gz как есть: без
content-encoding=gzip и с content-type=application/octet-stream

-- 
sergio.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: как работает gzip_static?

2020-05-03 Пенетрантность Maxim Dounin
Hello!

On Sun, May 03, 2020 at 05:22:33AM +0300, sergio wrote:

> Есть два файла: test.html и test.html.gz
> 
> Если gzip_static не указана, то отдаётся test.html
> (нет content-encoding=gzip в ff webdeveloper)
> 
> Если написать gzip_static on, то отдаётся test.html.gz
> (content-encoding=gzip в ff webdeveloper)
> 
> 
> 1. Если после этого удалить test.html то nginx отвечает 404, хотя ни
> https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html ни
> https://docs.nginx.com/nginx/admin-guide/web-server/compression/ не
> говорят ни слова, о том, что для этого должны присутствовать ОБА файла.
> 
> По-моему документацию стоит исправить.

Ответ 404 будет тогда и только тогда, когда файл test.html для 
чего-то используется и отсутствует на диске.  В случае, если 
запрос идёт непосредственно к файлу, клиент поддерживает gzip, и 
включён gzip_static - клиенту будет отправлен ответ из 
test.html.gz.

> 2. Так же ngx_http_gzip_static_module.html говорит:
> 
> With the “always” value .. It is useful if there are no uncompressed
> files on the disk anyway
> 
> Но переключние gzip_static с on на anyway при отсутствующем test.html
> ничего не меняет: nginx продолжает отвечать 404.

В случае с "gzip_static always;" меняется ровно одно: становится 
не важно, поддерживает ли клиент gzip, или нет - всегда будет 
отправлен сжатый ответ.  Если вы и в этом случае видите ответ 404, 
то это означает, что до gzip_static дело не доходит, и ответ 404 
отправляется раньше.

Например, так может быть, если у вас в конфиге стоит что-нибудь 
вроде "try_files $uri =404;", то есть существование конкретного 
файла проверяется явно.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

2020-05-03 Пенетрантность Maxim Dounin
Hello!

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:

> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> > 
> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как 
> > на сервер, так и на канал.  И статистика как бы говорит нам, что в 
> > среднем эти накладные расходы - больше, чем польза.
> 
> Я таковой статистикой не располагаю.

Ссылку на статистику я привёл.  Если вы не располагаете другой - 
вероятно, другой и нет.

> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.

По ресурсам "получить push" и "сделать дополнительный запрос и 
получить на него ответ" - строго одно и то же.  Разница - только во 
времени, полученный push будет доступен чуть раньше, что в хорошем 
случае немного сократит время до показа страницы.  А в плохом - 
потребует передачи по сети дополнительных данных (начала push'а и 
его отмены) и приведёт к увеличению времени до показа страницы.  
Именно на баланс "хороших" и "плохих" случаев и стоит смотреть.

> > Что будет конкретно в вашем случае - зависит, безусловно, от 
> > конкретной нагрузки и от того, насколько "в крайнем случае 
> > несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в 
> > среднем - будет хуже, потому что "в крайнем случае" никто не 
> > заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы 
> > тестировать, что получится.  Подозреваю, что от банального 
> > перекладывания существующих  в push'ы - 
> > станет только хуже.
> 
> Да, я понял Вашу точку зрения.
> Да, узкого эксперимента я не проводил.
> 
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > > 
> > > Не совсем понимаю какие выводы делают авторы.
> > > 
> > > Предлагают работать над приоритезацией (которая и так корректная, и
> > > регулируется preload'ом), использовать экспериментальный QUIC,
> > поддержики
> > > которого толком нет.
> > 
> > Авторы ясно и однозначно показывают, что server push - в среднем 
> > вредит, и в большинстве случаев лишь способ выстрелить себе в 
> > ногу.  И предлагают работать над другими технологиями, 
> > потенциально более полезными.
> > 
> > Тут важно понимать, что речь идёт про взгляд разработчиков 
> > браузера, и рассказывалось это всё на HTTP working group, то есть 
> > в рамках встречи людей, занимающихся разработкой протокола.
> 
> Из Ваших соображений и трактовке вышеприведённого исследования складывается
> впечатление, что даже разработчики протокола не донца понимают зачем push
> нужен.
> При том, что не только они описали его в протоколе, но и сторонние
> разработчики реализовали поддержку push'а клиентах и нескольких серверах.

Зачем нужен push - все понимают.  Насколько он при этом полезен 
для интернета в среднем - можно выяснить только практически.  Вот 
есть исследование от команды одного из браузеров, которое говорит, 
что в среднем - вреден.  

Что до "реализовали поддержку push'а", то вот мы - всегда считали, 
что полезность push'а, мягко говоря, преувеличена.  Но, тем не 
менее, вынуждены были реализовать, просто мотому, что пользователи 
читают маркетинговые материалы, рассказывающие о новом красивом 
протоколе HTTP/2 и его замечательных возможностях.  А понимать, 
какие недостатки есть у этих замечательных возможностей - не 
пытаются.

> > (Ну и да, про приоритезацию - смешно.  Нет, это не про preload, 
> > это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с 
> > бассейном и джакузи запроектирован в рамках стандарта, корректности 
> > ждать не приходится.)
> 
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.

Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная 
вещь, и именно она и упоминается в соответствующем докладе.  И с 
ней проблемы, именно потому она там и упоминается.

> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> > 
> > Именно с этого я и начал: попробуйте на практике на отдельных 
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот 
> > этого всего.  Получите статистику, сравните.
> > 
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, 
> > потому что оно точно будет лучше, но тестировать вы ничего не 
> > тестировали и не хотите. 
> 
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.

И получили на него ответ.  А равно рекоменацию о том, с чего 
начать, если вы вдруг считаете, что вам, тем не менее, надо.

Но почему-то пытаетесь спорить, убеждая меня в том,