- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
grayscale, это лишь выключает буферизацию ответа, но не запроса. поэтому все тиражируемые скрипты загрузки файлов советуют апач. о специальных разработках под nginx речь не идет.
окей
апач + сквид -- нет ошибки
апач + ngnix -- есть
и с какой стороны тут бекенд виноват?
может у сквида таймаут другой?
Если было бы просто перенести правила htaccess apache на lighttpd, то последний бы спокойно заменил apache + nginx вместе взятых. А если сравнивать только фронтенды, то практически nginx ~ lighttpd по отдаче. Только на последний практически нет литературы на русском языке.
502 это проблема nginx, и появляется даже на ненагруженном сервере, с lighttpd такого не бывает.
Хе... "Система"... "Платформа"...
.htaccess умеет и RewriteRule - вот по-этому и работает :-)
Но ведь есть Rewrite и в nginx.
Если было бы просто перенести правила htaccess apache на lighttpd, то последний бы спокойно заменил apache + nginx вместе взятых. А если сравнивать только фронтенды, то практически nginx ~ lighttpd по отдаче. Только на последний практически нет литературы на русском языке.
502 это проблема nginx, и появляется даже на ненагруженном сервере, с lighttpd такого не бывает.
То есть, ошибка 502 - это ошибка разработчика nginx?
WSGU, правила под апач, с таким-же успехом можно переписать под nginx.. в чем проблема-то..? в любом случае, на мой взгляд, это использование функционала веб-сервера для затыкания дыр в движке, то есть программеры, свалили часть своих обязанностей(заботу о безопасности приложения) на администраторов. .)
netwind, насколько я знаю, под nginx есть соответствующий модуль.. вы-же не хотите сказать что апач без сторонних модулей работает..
502 это проблема nginx, и появляется даже на ненагруженном сервере
.. что значит "даже" ?
502 - это не проблема самого nginx.. разбираться нужно с конфигами nginx + бакэнды.. fastcgi, apache, или что там еще крутиться..
окей
апач + сквид -- нет ошибки
апач + ngnix -- есть
и с какой стороны тут бекенд виноват?
Крошка, спили мушку. Тьфу, сотри подпись.
Andreyka добавил 27.05.2009 в 07:51
Если было бы просто перенести правила htaccess apache на lighttpd, то последний бы спокойно заменил apache + nginx вместе взятых. А если сравнивать только фронтенды, то практически nginx ~ lighttpd по отдаче. Только на последний практически нет литературы на русском языке.
502 это проблема nginx, и появляется даже на ненагруженном сервере, с lighttpd такого не бывает.
Попробуй настроить лайти на 200k запросов и посмотришь что с ним будет 😂
Но ведь есть Rewrite и в nginx.
Есть. Придется дать доступ клиенту к include в nginx.conf? и к reload'у? + уточните сколько из знакомых с .htaccess осилят синтаксис nginx )
nginx+apache
netwind, насколько я знаю, под nginx есть соответствующий модуль.. вы-же не хотите сказать что апач без сторонних модулей работает..
хочу сказать что без сторонних модулей работает апач. просто он запускает скрипт ДО того как все тело будет получено, а nginx ждет всего тела.
То есть, ошибка 502 - это ошибка разработчика nginx?
Это ошибка связки nginx с apache. Скорее всего, nginx формирует запрос для apache так, что в каких то обстоятельствах последний этот запрос не принимает, а nginx ждёт ответа. Вот и имеем знаменитую 502.... Эта проблема существует только в связке nginx+apache. В других комбинациях фронтенд_веб_сервер+apache такой ситуации не бывает (без явной проблемы у самого apache).
Это ошибка связки nginx с apache. Скорее всего, nginx формирует запрос для apache так, что в каких то обстоятельствах последний этот запрос не принимает, а nginx ждёт ответа. Вот и имеем знаменитую 502.... Эта проблема существует только в связке nginx+apache. В других комбинациях фронтенд_веб_сервер+apache такой ситуации не бывает (без явной проблемы у самого apache).
А нельзя в логах найти этот 502 запрос и проанализровать, что там не так с ним и чем он отличается от остальных, что апач не хочет его корректно отработать?