#c# #php #webclient
#c# #php #webclient
Вопрос:
Недавно я создал приложение, в котором допустил глупую ошибку, жестко привязав URL, на который я хочу отправлять данные, вместо использования прокси, такого как no-ip.
Короче говоря, это приложение регулярно отправляет запросы на мой сайт, что привело к потреблению большого количества ресурсов на моем сайте. Запрос отправляется на страницу PHP, которая не существует на моем сайте:
http://www.example.com/non-existing-page.php
Я подозреваю, что невозможно запретить распределенному приложению отправлять запросы на мой сайт без изменения URL моего веб-сайта.
Дело в том, что я не могу изменить URL и перенести свой сайт на другой URL, поэтому сейчас мне нужно знать, что мне следует сделать, чтобы сделать эту глупую ошибку менее ресурсоемкой.
1- Оставить все как есть
или
2- Создание пустого php с именем вызываемого скрипта..
Вот короткий вопрос: когда я вызываю страницу на удаленном сервере через WebClient, какая вещь потребляет больше ресурсов сервера, вызывая пустую страницу php или вызывая несуществующую страницу php..
Заранее спасибо
Комментарии:
1. в любом случае вы расходуете серверное время, но, по крайней мере, несуществующей странице не придется запускать подсистему PHP, поскольку веб-сервер может отклонить запрос, когда проверяет, является ли «foo.php «на самом деле существует или нет.
2. Вы должны спросить, какая из них дает значимый ответ клиентскому приложению …. использование перенаправления 301 может быть лучшим решением
3. Да! Я знаю, что любой способ не является решением.. но вы имеете в виду, что вызов несуществующей страницы будет потреблять меньше ресурсов. я прав? @MarcB
Ответ №1:
В общем широком смысле, будет ли отображаться страница 404 или нет, зависит от браузера.
IE не отображает пользовательскую страницу 404, если она не превышает 512 байт. Смотрите здесь То же самое и с chrome.
Если вы хотите разместить пользовательскую страницу 404, убедитесь, что вы включили в нее значок. В противном случае это приводит к действительно длительному времени загрузки. Подробно обсуждалось здесь