Состоялся (http://www.lighttpd.net/2019/1/27/1.4.53/) релиз легковесного http-сервера lighttpd 1.4.53 (http://www.lighttpd.net). В новой версии представлено 42 изменения, из которых большинство связано с исправлением ошибок. Из новшеств можно выделить добавление поддержки работы lighttpd в связке с systemd с активацией по сокету и реализацию расширения TLS-ALPN-01 (RFC 7301, Application-Layer Protocol Negotiation (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Neg... которое используется в HTTP/2 (непосредственно HTTP/2 в lighttpd пока не поддерживается).
Разработчики lighttpd также напоминают о грядущем изменении настроек по умолчанию, связанных с нормализацией URL при обработке HTTP-запросов. В первом квартале 2019 года будут активированы опции (https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_h... жёсткой проверки значений в заголовке Host, а также включена нормализация передаваемых в заголовках ссылок и блокирование ссылок с неэкранированными управляющими символами. В процессе нормализации будет включено автоматическое преобразование '\' в '/', "%2F" в "/", '%20' в '+', разрешение и удаление частей файловых путей с каталогами '.' и '..', декодирование экранированных символов '-', '.', '_' и '~'.
URL: http://www.lighttpd.net/2019/1/27/1.4.53/
Новость: https://www.opennet.me/opennews/art.shtml?num=50036
Еще лет через 10, когда вся сеть перейдет на HTTP/3 aka QUIC, в lighttpd осилят сделать частичную поддержку HTTP/2, правда она будет вызывать падение сервера с предоставлением ремотного рутового шелла любому, но это уж извините, на больее они все равно не способны.
quic - всего лишь тупая надстройка над udp. Вся сеть не перейдёт на это никогда. Веб может, он такой, туда ему и дорога.
Для тех, кто использует lighttpd, http2 не так уж и уперся, как вы тут рисуете.
а мы поддержку 1 и меньше скоро дропнем.
А как додавим переход всех и вся на 3 - так и 2 дропнем.И те кто используют - строем пойдут на наш прекрасный хостинг. Ну а лучше просто размещайте свои приложения в нашем облачке - и не парьтесь, какой там сервер, какие там протоколы - в единственно-правильном браузере всегда все будет работать, мы гарантируем.
Использую nginx перед lighttpd в том числе для HTTP/2.
Ну и ещё потому что реверс-прокси у nginx гораздо лучше, чем у lighttpd (это понадобилось для других задач тоже, а не только чтобы сам nginx воткнуть).
Но вот настроить nginx как полный сервер и отказаться от lighttpd так и не вышло за несколько подходов, настолько ограничены и неудобны конфиги в nginx.
конфиги у nginx, конечно, г-но то еще, но ниасилить его настроить в такой конфигурации, с которой справляется light - это надо какой-то специальный талант иметь.Поделитесь, что-ли, достиженями, а то хочется ж просто поржать, а новости нашего городка последнее время - одна тошнотворнее другой.
> конфиги у nginx, конечно, г-но то еще, но ниасилить его настроить в
> такой конфигурации, с которой справляется light - это надо какой-то специальный
> талант иметь.
> Поделитесь, что-ли, достиженями, а то хочется ж просто поржать, а новости нашего
> городка последнее время - одна тошнотворнее другой.Ну давай поржи: https://www.reddit.com/r/nginx/comments/7qj65w/combining_fas.../
только один из примеров
Всё достаточно просто, если иметь представление о том, как nginx обрабатывает location:
https://nginx.org/ru/docs/http/request_processing.html#simpl...
Т.е. для решения проблемы достаточно второй location сделать regexp и поместить выше первого, что собственно и объясняется в документации:
> nginx вначале ищет среди всех префиксных location’ов, заданных строками,
> максимально совпадающий. В вышеприведённой конфигурации указан только один
> префиксный location “/”, и поскольку он подходит под любой запрос, он и будет
> использован, если других совпадений не будет найдено. Затем nginx проверяет
> location’ы, заданные регулярными выражениями, в порядке их следования в
> конфигурационном файле. При первом же совпадении поиск прекращается и nginx
> использует совпавший location. Если запросу не соответствует ни одно из
> регулярных выражений, nginx использует максимально совпавший префиксный location,
> найденный ранее.Т.е. вместо написания конфигурации под вашу задачу на ПО №1 вы предлагаете поставить дополнительное программное обеспечения, которое умеет это из коробки, причём заменить ПО №1 оно не может и вы будете поддерживать зоопарк просто потому, что не смогли в ПО №1. Рекомендую вам вместо iptables пользоваться firewalld, а вместо apt использовать synaptic в виду удобства последних
вот насчет synaptics это кто-то со зла ;-)а так да, какой-то совсем скучный пример. То есть его нельзя даже отнести к уродству nginx-конфигов, оно вполне в этом месте разумно.
> вот насчет synaptics это кто-то со зла ;-)
> а так да, какой-то совсем скучный пример. То есть его нельзя даже
> отнести к уродству nginx-конфигов, оно вполне в этом месте разумно.Держите повеселее:
http://rosslawley.co.uk/archive/old/2010/01/04/nginx-how-to-.../
в этом вся ограниченность и долбанутость его конфиг-системы просто в концентрированном виде.А в Lighttpd просто полноценные nested if'ы.
вообще не вижу проблемы, кроме той что автор не потрудился почитать документацию и выдает тривиальнейший пример за мегасложное решение.в общем, судя по ссылкам на какие-то левые васян-блоги, никакой реальной проблемы которую решает только lighttpd у вас нет.
или покажите же уже наконец _ваш_ конфиг, а мы и посмотрим - нужны там в случае nginx эти nested if'ы, или можно сделать в разы проще.
>[оверквотинг удален]
> первого, что собственно и объясняется в документации:
>> nginx вначале ищет среди всех префиксных location’ов, заданных строками,
>> максимально совпадающий. В вышеприведённой конфигурации указан только один
>> префиксный location “/”, и поскольку он подходит под любой запрос, он и будет
>> использован, если других совпадений не будет найдено. Затем nginx проверяет
>> location’ы, заданные регулярными выражениями, в порядке их следования в
>> конфигурационном файле. При первом же совпадении поиск прекращается и nginx
>> использует совпавший location. Если запросу не соответствует ни одно из
>> регулярных выражений, nginx использует максимально совпавший префиксный location,
>> найденный ранее.Всё равно это костылинг и пердолинг. В lighttpd всё гораздо красивее и проще.
> Т.е. вместо написания конфигурации под вашу задачу на ПО №1 вы предлагаете
> поставить дополнительное программное обеспечения, которое умеет это из коробки, причём
> заменить ПО №1 оно не может и вы будете поддерживать зоопарк
> просто потому, что не смогли в ПО №1. Рекомендую вам вместо
> iptables пользоваться firewalld, а вместо apt использовать synaptic в виду удобства
> последнихСуть такова что это как раз lighttpd стоит там с незапамятных времён и со своими задачами справляется, nginx же был поставлен совсем недавно "сбоку" ради некритичных задач вроде более эффективого реверс-прокси и поиграться с HTTP/2. А так, по большому счёту не нужен, и может быть удалён. Так что в вашем примере это "ПО №1" является "дополнительным программным обеспечением" на птичьих правах, а рабочий продакшен конфиг давно живёт и работает на ПО... №0? то бишь на lighttpd.
вас склоняют использовать то, что хотят они, а вы не поддаётесь. Вы плохой.
да не, не склоняем, нафиг нам надо - скажи честно "не умею настраивать и учиться не хочу", но нет, надо распространять дезу что конфиг не такой, функционал не такой, только light спасет мир.А хочешь узнать (вдруг в твоих заниях пробел и он правда где-то там спасает мир) - а в ответ реддит тухлый :-(
Ну вот, написал ответ, а его удалили. Нахер такой форум и модератор думаю прочитал уже что я о нём думаю и чего ему искренне желаю.
> ПО №1Бгггггг
К гадалке сегодня уже не пойду? Вы сделали мое утро ;)
И да, сходите проверьте уровень желчи в черепной коробке.Долгие лета lighttpd!
Думаю, что они с их способностями, сами разберутся как "падать", и какую сторону взлетать и кому предоставлять рутовый шелл!
Как-то, лет 10 назад, поставил сей сервер для производственных задач, так и беды с ним не знаю.
Особенно помог, когда необходимо было одни задачи под PHP5 пускать, а другие уже на PHP7 перевелись. На нём это очень элементарно настроилось.
Удачный сервер, полностью оправдывает своё имя LIGHT.
Переход на Apache и Nginx не планирую, и, даст бог, ещё долго не запланирую.
Это он при отдаче файла полностью копирует его в буфер? :)