- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Т.е. большой proxy_buffer_size и proxy_buffering off? Так и сделали в тот раз, но проблема медленных коннектов осталась.
Вполне логично, нет? Пакет никому нафиг не упал, никто им не занимается и не исправляет *важные* проблемы. Нужно такое держать дальше?
У пользователя ОС на этот пакет могла быть завязана какая-то логика -- если не знаешь, будешь ли поддерживать пакет, то не бери его в основной репозиторий ОС. Если бы был какой-то базовый репозиторий софта, который гарантированно всегда будет поддерживаться, и это было бы подробно описано, то Debian можно было бы использовать для серьезных дел.
Потому что это не несёт смысла -- статика будет жить в двух местах на диске, и в общем случае клиентская логика может быть сложнее (например, рерайтами в зависимости от IP отдавать разные большие файлы) и неправильно реализованной (expires 1 jan 1970 не проставляется).
Что имеет смысл -- переписать mod_aclr под apache2. Вроде как, зенон справился, но не выложил. Это и проблему с симлинками решит (но оставит race condition), и с рерайтами, и с хтакцессами.
Кстати, если запретить отдачу статики, проблема всё равно остаётся на 99% конфигов.
Вроде как не сильно зависит: Symbolic links in earlier components of the pathname will still be followed. (c) man 2 open.
а, ну да, по второй ссылке Сысоев несколько про другое писал писал:
O_NOFOLLOW
If the path names a symbolic link, open() fails and sets errno to
ELOOP.
O_NOLINKS
If the link count of the named file is greater than 1, open() fails
and sets errno to EMLINK.
а, ну да, по второй ссылке Сысоев несколько про другое писал писал:
Ага. Но ни в Linux, ни в FreeBSD такого флага нет :(
У пользователя ОС на этот пакет могла быть завязана какая-то логика -- если не знаешь, будешь ли поддерживать пакет, то не бери его в основной репозиторий ОС.
Ну и где был это мифический пользователь - когда надо исправить ошибку? На момент релиза можно запросто и "не знать" дальнейшую судьбу ПО. Может upstream его забросит вообще. Может тот мейнтейнер, что вел пакет - передумал им заниматься.
Если бы был какой-то базовый репозиторий софта, который гарантированно всегда будет поддерживаться, и это было бы подробно описано, то Debian можно было бы использовать для серьезных дел.
Смотрите на статистику popcon. Активно использующиеся пакеты (100+) - никто не выкинет. Полюбопытствуйте - это очень солидная база, на порядок больше объедков, которые вам RHEL слил через всякие CentOS.
Удаление пакетов из stable - это вообще, скорее, исключение, нежели практика. В конце-концов, я же привел примеры. Так что вы вполне можете воспринимать как гарантию: пока на ПО не начхать абсолютно никому - из stable его не выкинут.
Потому что это не несёт смысла -- статика будет жить в двух местах на диске
*Не вся* статика. И не всегда. А еще в памяти может часть жить - как кеширование настроите.
и в общем случае клиентская логика может быть сложнее (например, рерайтами в зависимости от IP отдавать разные большие файлы) и неправильно реализованной (expires 1 jan 1970 не проставляется).
В зависимости от того, насколько сложнее и нужно думать. Если что-то "неправильно" - исправить. В то, что nginx магически все решит - я не верю, извините.
Ага. Но ни в Linux, ни в FreeBSD такого флага нет :(
Вроде кроме соляриса оно только в Hurd есть(было?):
http://lkml.indiana.edu/hypermail/linux/kernel/0709.1/1467.html
Обещают счастье через 3 недели http://trac.nginx.org/nginx/milestone/1.1.14
Это хорошо через 3 недели проверим
Судя по чейнжлогу, счастье прошло мимо:
Изменения в nginx 1.1.14 30.01.2012
*) Добавление: теперь можно указать несколько ограничений limit_req
одновременно.
*) Исправление: в обработке ошибок при соединении с бэкендом.
Спасибо Piotr Sikora.
*) Исправление: в обработке ошибок при использовании AIO на FreeBSD.
*) Исправление: в инициализации библиотеки OpenSSL.
*) Исправление: директивы proxy_redirect могли наследоваться
некорректно.
*) Исправление: утечки памяти при переконфигурации, если использовалась
директива pcre_jit.
P.S. По новому плану разработки, должны поправить в версии 1.1.15 http://trac.nginx.org/nginx/milestone/1.1.15
Сделали
http://trac.nginx.org/nginx/changeset/4478/nginx
Сделали
http://trac.nginx.org/nginx/changeset/4478/nginx
Также как и в апаче, ничего нового не придумали. Только лет на двадцать (?) позже. И после того как дырка пожила в сервере лет 7-8. Just to note.
Упустил топик из виду. На сколько вижу, реализации разные, и в nginx исключен race condition, но надо права на search на каждый элемент пути. Также, есть возможность задания префикса, откуда проверять, для экономии на нескольких сисколах выше хоумдиров.