Я немного запутался в том, как работают URL. Раньше, когда я изучал HTML и все такое, я знал, что то, что идет после имени домена, — это местоположение файла, который мы хотим загрузить (например, website.com/somefolder/somefile.html). И это было просто, я мог это понять.
Недавно мне пришлось узнать больше о вебе, и я увидел, что URL-адреса стали сложнее. Например:
- ссылки drupal выглядят как somewebsite.com/node/43
- Запросы REST похожи на somewebsite.com/books/32
- после '?' можно передать некоторые параметры
Как это работает? Как сервер (или что-то еще? Я совсем новичок) узнает, что означает URL, когда получает запрос? Это может быть:
- расположение ресурса
- вид drupal
- REST-запрос
- что-то еще?
Не знаю, имеет ли смысл мой вопрос, но надеюсь, вы понимаете, в чем причина моего замешательства.
решение1
Как это работает?
Решение принимает сервер.
Как сервер (или что-то еще? Я совсем новичок) узнает, что означает URL, когда он получает запрос?
Сервер полагается на свою конфигурацию. Для серверов на базе Unix это часто обрабатывается одним или несколькими текстовыми файлами, которые часто называются файлами «конфигурации». При настройке сервера вы можете указать это. Подробности того, как указать это, будут различаться в зависимости от того, какое программное обеспечение веб-сервера вы используете.
(Обычно существует множество руководств по популярным веб-серверам и пакетам CGI, поэтому, если администратор веб-сайта не знает, как это сделать, он обычно начинает читать примеры/документацию/руководства. Поэтому, если вы ищете документацию по веб-серверу, такому как Apache, вы, скорее всего, сможете найти информацию о настройке Drupal. С другой стороны, если вы ищете информацию о чем-то вроде Drupal, вы, скорее всего, найдете раздел документации о том, как настроить Apache для использования Drupal. При таком количестве доступной документации администраторам веб-сайтов обычно не нужно слишком сильно напрягаться, чтобы найти соответствующие сведения о программных пакетах, которые они хотят использовать.)
Клиент HTTP 1.1 имеет тенденцию разбивать URL на три части:
- Протокол (например, http/https)
- Сайт (например example.com)
- ресурс (например, /somedir/file.htm)
Это может быть небольшим упрощением. Некоторые старые URL допускали что-то вродеftp://имя_пользователя@пароль:example.com/somedir/fileхотя более новые веб-браузеры, как правило, удаляют такую поддержку, напримерМС КБ 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/ локального жесткого диска, за исключением /cgi-bin/, который будет запускать программу, расположенную в /cgi-bin/, а все, что находится в /scripts/ и заканчивается на .pl, будет запускаться интерпретатором PERL.
Конкретные детали различаются в зависимости от конфигурации веб-сервера, поэтому не существует универсального стандарта, который скажет веб-клиенту, можно ли гарантировать получение копии статической страницы или вывода запущенной программы. Все, чего может ожидать веб-клиент, это то, что если веб-клиент запросит ресурс, веб-сервер ответит на него.
решение2
Веб-сервер незнатьлюбое из этих значений – во всех случаях он просто получает путь к ресурсу, пропускает его через основную программу веб-сайта и отправляет вам полученный вывод. И, конечно, разные программы делают разные вещи с указанным им путем.
Если программа не настроена, она ищет файл с таким именем и обслуживает его напрямую. (PHP и CGI часто находятся где-то посередине: веб-сервер все равно ищет файл, но затем запускает этот файл)самкак программа.)
Так что единственное, /node/43что делает это "представлением Drupal", это то, что веб-сервер настроен на передачу /node/<anything>программному обеспечению Drupal. Веб-страница по-прежнему считается ресурсом, даже если она была динамически сгенерирована.
(Сам Drupal, конечно, знает, что если путь начинается с /node/, то за ним будет следовать идентификатор представления.)
Запросы REST также являются совершенно обычными запросами ресурсов; «RESTful» их делает только общий стиль и поведение. (Например, URL-адреса в стиле /book/345соответствуют идеологии REST, а /api/get_book?id=345не соответствуют.)