Комментарии 60
Ну, т.е. странно что обращение к "/favicon.ico" и "/comment/" какой-нибудь обрабатываются одинаково
В результате любой 404 может превратиться в нагрузку на сервер.
Проблема для продакшена не частая — почти любой сайт имеет favicon, но тем не менее.
Во-первых, есть кейс, когда пользователя с 404 лучше отправить на home page, чтобы он не ушел. Во-вторых, иногда даже 404 страница должна быть не просто статикой (редко, но бывает).
Ну так делайте динамический переход с помощью JavaScript.
А еще есть прикол с Referer при редиректе через js (иногда это тоже важно). При серверном редиректе referer нового запроса будет первоначальная страница, а при js редиректе — текущая страница.
Иногда js в браузере может быть выключен и иногда все же есть требования, чтобы сайты работали без js
Для этого существует тэг noscript. Включены скрипты — пользователь видит пустую страницу, с которой тут же идёт переход. Выключены скрипты — пользователь получает простую статическую страницу.
А еще есть прикол с Referer при редиректе через js (иногда это тоже важно). При серверном редиректе referer нового запроса будет первоначальная страница, а при js редиректе — текущая страница.
Это случится, если при некорректном запросе сначала делать редирект на страницу 404, а не отдавать код сразу.
— пользователь пришел на 404.html и ушел, это не то, что он ожидал увидеть и ничего, что привлекло бы его внимание тут нету. пользователь ушел.
серверный редирект позволит сразу его перекинуть на хомпейдж, и там уже есть вероятность, что он задержится дольше, чем на 404.html
А решение проблемы с /favicon очень простое — нужно правильно настроить рулы редиректа. Для всех картинок прописать 404, без редиректа, а для 404 при запросе html — прописать редирект на хомпейдж. Велосипедов придумывать не нужно, все уже давно известно.
> Это случится, если при некорректном запросе сначала делать редирект на страницу 404, а не отдавать код сразу.
сценарий:
— пользователь из внешнего источника «А» тыкает на ссылку, которая ведет на отсутствующую страницу (почему отсутствует — другой вопрос).
страницы нету — он попадает на 404.html, на которой стоит редирект на хомпейдж. перейдя на хомпейдж — у него в referer будет 404.html, а не «ресурс А»
единственный способ сохранить referer — серверный редирект.
А решение проблемы с /favicon очень простое — нужно правильно настроить рулы редиректа.
Да, это более правильный способ.
страницы нету — он попадает на 404.html
А зачем делать редирект на 404.html, когда можно просто отдать код страницы?
Тогда в Referer будет не 404.html, а адрес некорректного запроса. Если же позарез нужен именно «ресурс A», тогда можно его передавать через параметры запроса.
Впрочем, возни с сервисами аналитики это прибавит.
Спасибо, интересный вариант, про него не подумал про него!
Но есть 2 «но»:
1. Отдав контент и далее сделав редирект — Referer у редиректа будет запрошенная страница (которой нету).
2. Этот вариант займет больше времени. Сначала нужно доставить контент (объем больше, чем у пустого редиректа), потом нужно будет этот контент отрендерить, и лишь потом будет выполнен редирект.
Моя позиция в том, что для сохранения referer нужно делать 3xx редирект html контента.
В сообщениях выше по этой ветке коллеги предлагают отдать контент и уже из контента делать редирект. Отдать html контент с 404 кодом, даже если и получится, то это не правильно.
И если таки отдать 404.html — то при редиректе с нее в реферер будет установлен 404.html, а не ресурс, с которого пришли.
Все-таки лучше не сразу отправлять на главную, а показать 404 и, если уж так надо, то добавить мета-тег c [http-equiv="refresh"], чтобы пользователя перекидывало на главную через несколько секунд (работает без JS):
<meta http-equiv="refresh" content="3; URL=http://example.com/">
Запись в базу — это тупость, без сомнения. Судя по всему, автор хотел нагнать паники «Мы все умрем».
А так же бизнес кейсы бывают разные. Не все делается на фронтенде, как бы этого не хотелось многим.
Банально у автора неправильно настроена обработка путей. Это довольно частая проблема, среди тех кто любит бездумно все запросы заворачивать на index.php.
Не поставил favicon на сайте, халтурно сокнфигурировал Apache и по-дурацки организовал работу скриптов и БД — получи двойной трафик от Chrome
А одно из предложений в тексте так:
… большинство .htaccess файлов в Apache, которые я написал для своих сайтов, имеют в себе строчки...
Почему две вставки происходит? Хром обратится GET-запросом напрямую к /favicon.ico. Никаких данных в POST или GET быть не должно. С чего вдруг двойное выполнение insert? Тогда получается любой 404ый запрос с этой страницы может косячить, даже аякс?
Реквестирую подробности рассказа о том как комментарии в базу вставляются по GET-запросу да ещё и без дополнительных данных.
А вообще, нагрузку увеличить Хром и правда может не только как тут в комментах уже писали о user-friendly 404, но и при наборе в адресной строке конкретного адреса: prefetch-логика шлёт два GET-запроса, что дважды загружает страницу, инкрементирует дважды счётчики, даже может сбросить выделение непрочитанных данных в некоторых случаях.
Вы мне лучше расскажите, почему попадание на несуществующую страницу увеличивает счетчик заходов? Пользователь никуда не попал (404 == страницы нет)? Какая в этом логика подсчета? Хотите редирект — ок, перенаправьте и там засчитайте.
Завтра к вам зайдут с iPhone/iPad и он запросит картинку apple-touch-icon.png. Еще строчку добавите в .htaccess?
Вот где проблема: вы не хотите исправить кривое решение, а хотите обставить костылями по кругу.
Жду еще 20 статей такого же рода, про каждый новый тип картинки.
Вся проблема кроется в Crome
А по делу:
1. плохо настроен modrewrite (10%);
2. Ошибка в написании велосипеда, а именно в обработке «404 Not found» — скорее при обработке передаются все параметры запроса и если автор обрабатывает параметры в одном месть, то параметр на событие повторяется (например, index.php?act=comment) — не обязательно get, скорее всего запрос обрабатывается, через Request.
Статья должна называться: «как я несколько лет косячил с настройками apache и не проверял входящие данные в PHP».
Я открою вам секрет: не только в Chrome так. Многие браузеры во время совершения ajax запроса шлют сначала OPTION запрос для принятия заголовков Allowed-*, например.
Пересмотрите свое отношение к написанию кода, я прямо чувствую там дуршлаг )
Я бы посоветовал почитать книжки про сетевой стек, поизучать как запросы вообще приходят на сервер, используя протокол HTTP, как можно эти запросы анализировать и делать выводы, а не «Далее идут поиски некорректно работающих яваскриптов, расширений для браузера, но все безрезультатно. Поиск по интернету давал схожие советы. Многие программисты в аналогичной ситуации вводили проверку на уникальность и отсекали дублирующиеся посты.»
Еще в Developer Tools есть замечательная вкладка Network, где можно посмотреть все запросы, которые отправляет браузер
Соглашусь с комментаторами выше, почему на 404 GET запросе происходит insert?
Если вы пишите свою систему статистики посещений, то:
- во-первых не стоит записывать каждый HTTP запрос (Это уже не статистика а логгер, который легко настроить на HTTP сервере).
- во-вторых исключите обработку своим index.php запросы на статику по паттернам (прим. /assets/*, /favicon.ico, /robots.txt, /sitemap.xml), даже если файлов таких нет, в дальнейшем вы избежите подобных проблем.
- в-третьих никакого двойного трафика нет, у вас так-же происходят запросы на получение js, css и т.п
.З.Ы. Помню была немного похожая ситуация с хромом:
Писал платежные шлюзы которые тестировались через GET запрос аля: http://{ip}/gatewayName.php?params....
через какое-то время обнаружил что один шлюз начал переодически самопроизвольно запускаться, после долгого исследования обнаружил что хром добавил url в стартовую панель и переодически пытался обновить preview страницы.
На язвительные комментарии отвечу, что речь в статье шла о необычном поведении браузера Chrome (другие браузеры не особо докапываются до отсутствия иконки) и о том, к чему это может привести в случае некорректно настроенного .htaccess на сервере. (А он такой по дефолту во многих open source движках, например Wordpress, так что думаю, проблема может оказаться распространенной). Например, я бы ожидал столкнуться с отсутствующими файлами в upload директории сайта, ну или в папке с темой оформления, но забыл бы про корень сайта. Статья никоим образом не должна иллюстрировать грамотные подходы к созданию современных сайтов.
А про SELECT — тестировал новый метод класса на локалхосте. Сознательно вбил его вызов напрямую в index.php и в браузере F5, F5, F5… Только ради теста. Не надо придавать этому значения.
— конфиг mod_rewrite;
— INSERT в БД по GET запросу;
— INSERT в БД без CSRF;
— определение причинно-следственной связи.
Школьнику/студенту еще простительно, но 5 лет разработки в вебе?
ps. Почитал комментарии. Товарищам, считающим, что ТС добавлял записи для счетчика просмотров — прошу прочитать первый абзац в статье чуточку внимательнее, где явно указано про форму комментариев. Хотя и с прямым взаимодействием (вставка/обновление) с БД при реализации счетчика просмотров я бы поспорил.
А конфиг-то дефолтный, наверное, для большинства систем с единой точкой входа :)
Не поставил favicon на сайте — получи двойной трафик от Chrome