URL como localizador de recursos ou outra coisa - como funciona?

Question

Estou um pouco confuso sobre como os URLs funcionam. Antigamente, quando eu estava aprendendo HTML e outras coisas, eu sabia que o que acontece depois do nome de domínio é a localização de um arquivo que queremos carregar (por exemplo, website.com/somefolder/somefile.html). E foi simples, eu pude entender isso.

Recentemente, tive que aprender mais algumas coisas sobre a web e vi que as URLs são mais complicadas. Por exemplo:

• links drupal são como somewebsite.com/node/43
• solicitações REST são como somewebsite.com/books/32
• depois de '? você pode passar alguns parâmetros

Como isso funciona? Como o servidor (ou alguma outra coisa? Sou novato) sabe o que significa URL quando recebe uma solicitação? Pode ser:

• localização do recurso
• visão drupal
• solicitação REST
• algumas outras coisas?

Eu não sei se minha pergunta faz sentido, espero que você entenda sobre o que é minha confusão.

    

Answer 1

How does that work?

O servidor decide.

How does the server (or something else? I'm quite novice) know what URL means when it gets a request?

O servidor depende de sua configuração. Para servidores baseados em Unix, isso geralmente é tratado por um ou mais arquivos de texto que geralmente são chamados de arquivos de "configuração". Ao configurar o servidor, você pode especificar isso. Detalhes sobre como especificar isso variarão com base no software do servidor da Web usado.

(Existem muitos tutoriais para servidores web populares e pacotes CGI, portanto, se um administrador de sites não souber como fazer isso, essa pessoa geralmente começa a ler exemplos / documentação / tutoriais. Então, se você procurar Na documentação sobre um servidor da Web como o Apache, é provável que você consiga encontrar informações sobre a configuração do Drupal. Por outro lado, se você procurar informações sobre algo como o Drupal, provavelmente encontrará uma seção da documentação sobre como configure o Apache para usar o Drupal Com tanta documentação disponível, os administradores de sites geralmente não precisam se esforçar muito para encontrar detalhes relevantes para os pacotes de software que desejam usar.

O cliente HTTP 1.1 tende a dividir a URL em três partes:

• O protocolo (por exemplo, http / https)
• O site (por exemplo, exemplo.com)
• o recurso (por exemplo, /somedir/file.htm)

Isso pode ser uma ligeira simplificação. Alguns URLs mais antigos permitiam algo como ftp: // nome de usuário @ senha: example.com/somedir/file embora mais recente navegadores da Web tendem a remover esse suporte, por exemplo, MS KB 8344389 , devido a preocupações com a segurança (incluindo uma quantidade significativa de abuso que ocorreu, por exemplo, link converteria o% 40 em ASCII 64, que é o @, fazendo com que o nome de usuário de paypal.com/gibberish fosse usado para efetuar login no PhishingSite.example.com, o que simplesmente aceitaria o login e pediria às pessoas a senha do PayPal. veria o paypal.com no início do URL e confiaria nele.

Claro, existem alguns "padrões", como # em uma URL, algo que o Web client reconhecerá e não enviará para o servidor. Em vez disso, o cliente da Web tratará o texto após o # como texto âncora para o qual saltar. Além disso,% é usado para escapar caracteres hexadecimais. Clientes da Web tendem a entender isso.

Outros detalhes podem estar no servidor. Por exemplo, muitos servidores da web têm? iniciar uma lista de parâmetros e usar o & (ou muitos um ponto e vírgula?) para dividir os parâmetros dentro da lista de parâmetros. No entanto, isso é simplesmente um comportamento comum exibido por muitos servidores da web. Não há parte do HTTP que force os servidores da web a honrar isso. Realmente, o servidor web pode lidar com isso do jeito que o servidor web quiser, e o web client provavelmente não precisará de nenhum suporte especial para isso.

Se você já configurou um servidor HTTP, provavelmente entenderá que parte dessa configuração está especificando o que fazer com os recursos solicitados. Por exemplo, você poderia dizer que tudo enviado para / irá carregar arquivos da área / srv / httpdocs / do disco rígido local, exceto para / cgi-bin / que executará um programa localizado em / cgi-bin / e qualquer coisa sob / scripts / e terminando com .pl será executado pelo interpretador PERL.

Os detalhes específicos variam de acordo com a configuração do servidor da web, portanto, não há um padrão universal que informe ao cliente da Web se ele pode receber uma cópia de uma página estática ou a saída de um programa que recebe corre. Tudo o que o cliente da Web pode esperar é que, se o Web client solicitar um recurso, o servidor da Web responderá a ele.

    

Answer 2

O servidor web não conhece nenhum desses significados - em todos os casos ele apenas recebe o caminho do recurso, o executa através do programa principal do site e envia a saída resultante. E é claro que diferentes programas fazem coisas diferentes com o caminho que receberam.

Se não houver nenhum programa configurado, ele procura por um arquivo com esse nome e o exibe diretamente. (PHP e CGI geralmente estão em algum lugar no meio: o servidor web ainda procura por um arquivo, mas então executa esse arquivo em si como o programa.)

Portanto, a única coisa sobre o /node/43 que faz dele uma "visualização do Drupal" é que o servidor da Web foi configurado para passar /node/<anything> para o software do Drupal. A página da Web ainda é considerada um recurso, embora tenha sido gerada dinamicamente.

(O próprio Drupal, é claro, sabe que se o caminho começar com /node/ , ele será seguido pela ID de exibição.)

Solicitações REST também são solicitações de recursos completamente regulares; o que os torna "RESTful" é apenas o estilo e o comportamento geral. (Por exemplo, URLs no estilo de /book/345 ajustam a ideologia REST, enquanto /api/get_book?id=345 não.)