Как это работает?
Сервер решает.
Как работает сервер (или что-то еще? Я довольно новичок) знаете, что означает URL, когда он получает запрос?
Сервер полагается на свою конфигурацию. Для серверов на основе Unix это часто обрабатывается одним или несколькими текстовыми файлами, которые часто называют файлами конфигурации. При настройке сервера вы можете указать это. Подробная информация о том, как это указать, зависит от того, какое программное обеспечение веб-сервера вы используете.
(Существует множество учебных пособий для популярных веб-серверов и пакетов CGI, поэтому, если администратор веб-сайта не знает, как это сделать, этот человек обычно начинает читать примеры / документацию / учебные пособия. Итак, если вы ищете документацию о веб-сервере, таком как Apache, вы, вероятно, сможете найти информацию о настройке Drupal. С другой стороны, если вы ищете информацию для чего-то вроде Drupal, вы, вероятно, найдете раздел документации о том, как настроить Apache для использования Drupal. Имея так много доступной документации, администраторам веб-сайтов обычно не нужно слишком сильно бороться, чтобы найти соответствующие детали для пакетов программного обеспечения, которые они хотят использовать.)
Клиент HTTP 1.1 имеет тенденцию разбивать URL на 3 части:
- Протокол (например, http/https)
- Сайт (например, example.com)
- ресурс (например, /somedir/file.htm)
Это может быть небольшим упрощением. Некоторые старые URL-адреса допускают что-то вроде ftp://username @ password:example.com/somedir/file, хотя более новые веб-браузеры, как правило, удаляют такую поддержку, например MS KB 8344389, из соображений безопасности (включая значительное количество злоупотреблений, которые произошло, например, http://paypal.com/gibberish%40PhishingSite.example.com/gibberish конвертирует% 40 в ASCII 64, который является @, в результате чего имя пользователя paypal.com/gibberish будет использоваться для входа в PhishingSite. .example.com, который просто примет логин и попросит людей ввести пароль PayPal. Люди будут видеть paypal.com в начале URL и доверять ему.
Конечно, есть некоторые "стандарты", такие как # в URL - это то, что веб-клиент распознает и не отправит на сервер. Вместо этого веб-клиент будет обрабатывать текст после # как текст привязки для перехода. Кроме того,% используется для экранирования шестнадцатеричных символов. Веб-клиенты, как правило, понимают это.
Другие детали могут зависеть от сервера. Например, у многих веб-серверов есть? запуск списка параметров и использование & (или много точек с запятой?) для разделения параметров в списке параметров. Тем не менее, это обычное поведение многих веб-серверов. Нет части HTTP, которая заставляет веб-серверы соблюдать это. Действительно, веб-сервер может справиться с этим так, как хочет веб-сервер, и веб-клиенту вряд ли потребуется какая-либо специальная поддержка для этого.
Если вы когда-нибудь настроите HTTP-сервер, вы, вероятно, поймете, что часть этой конфигурации указывает, что делать с запрошенными ресурсами. Например, вы можете сказать, что все, что отправлено в / будет загружать файлы с локального жесткого диска / srv / httpdocs / area, за исключением / cgi-bin /, который будет запускать программу, расположенную в / cgi-bin /, и все, что в / scripts / и заканчивающийся на .pl будет выполняться интерпретатором PERL.
Конкретные детали зависят от конфигурации веб-сервера, поэтому не существует универсального стандарта, который сообщал бы веб-клиенту, можно ли гарантировать получение копии статической страницы или вывод программы, которая запускается. Все, что веб-клиент может ожидать, это то, что если веб-клиент запрашивает ресурс, веб-сервер ответит на него.
