Estoy un poco confundido sobre cómo funcionan las URL. En los viejos tiempos, cuando estaba aprendiendo HTML y esas cosas, sabía que lo que va después del nombre de dominio es la ubicación de un archivo que queremos cargar (por ejemplo sitio web.com/alguna carpeta/algún archivo.html). Y era simple, podía entenderlo.
Recientemente tuve que aprender algunas cosas más sobre la web y vi que las URL son más complicadas. Por ejemplo:
- Los enlaces de Drupal son como somewebsite.com/node/43.
- Las solicitudes REST son como somewebsite.com/books/32
- después '?' puedes pasar algunos parámetros
¿Cómo funciona? ¿Cómo sabe el servidor (o algo más? Soy bastante novato) qué significa la URL cuando recibe una solicitud? Podría ser:
- ubicación del recurso
- vista drupal
- Solicitud de descanso
- algunas otras cosas?
No sé si mi pregunta tiene sentido, espero que entiendas a qué se debe mi confusión.
Respuesta1
¿Cómo funciona?
El servidor decide.
¿Cómo sabe el servidor (o algo más? Soy bastante novato) qué significa la URL cuando recibe una solicitud?
El servidor depende de su configuración. Para los servidores basados en Unix, esto suele ser manejado por uno o más archivos de texto que a menudo se denominan archivos de "configuración". Al configurar el servidor, puede especificar esto. Los detalles sobre cómo especificar esto variarán según el software de servidor web que utilice.
(Tiende a haber muchos tutoriales para servidores web populares y paquetes CGI, por lo que si un administrador de sitio web no sabe cómo hacer esto, esa persona generalmente comienza a leer ejemplos/documentación/tutoriales. Entonces, si busca documentación sobre un servidor web como Apache, es probable que pueda encontrar información sobre cómo configurar Drupal. Por otro lado, si busca información sobre algo como Drupal, probablemente encontrará una sección de documentación sobre cómo configurar Apache. use Drupal Con tanta documentación disponible, los administradores de sitios web generalmente no necesitan esforzarse demasiado para encontrar detalles relevantes para los paquetes de software que desean usar).
El cliente HTTP 1.1 tiende a dividir la URL en 3 partes:
- El protocolo (por ejemplo, http/https)
- El sitio (por ejemplo, ejemplo.com)
- el recurso (por ejemplo, /somedir/file.htm)
Esto puede ser una ligera simplificación excesiva. Algunas URL más antiguas permitían algo comoftp://nombredeusuario@contraseña:ejemplo.com/algundir/archivoaunque los navegadores web más nuevos han tendido a eliminar dicho soporte, por ejemploMS KB 8344389, por motivos de seguridad (incluida una cantidad notable de abusos que se han producido, por ejemplohttp://paypal.com/gibberish%40PhishingSite.example.com/gibberishconvertiría el %40 en ASCII 64, que es @, lo que provocaría que se usara el nombre de usuario de paypal.com/gibberish para iniciar sesión en PhishingSite.example.com, que simplemente aceptaría el inicio de sesión y pediría a las personas su contraseña de PayPal. La gente vería paypal.com al comienzo de la URL y confiaría en él.
Claro, hay algunos "estándares" como # en una URL es algo que el cliente web reconocerá y no lo enviará al servidor. En cambio, el cliente web tratará el texto después del # como texto de anclaje al que saltar. Además, % se utiliza para escapar de caracteres hexadecimales. Los clientes web tienden a entender eso.
Otros detalles pueden depender del servidor. Por ejemplo, ¿muchos servidores web tienen? comenzar una lista de parámetros y usar & (¿o muchos puntos y coma?) para dividir los parámetros dentro de la lista de parámetros. Sin embargo, ese es simplemente un comportamiento común que presentan muchos servidores web. No hay ninguna parte de HTTP que obligue a los servidores web a respetar eso. Realmente, el servidor web puede manejar eso como quiera, y no es probable que el cliente web requiera ningún soporte especial para eso.
Si alguna vez configura un servidor HTTP, probablemente comprenderá que parte de esa configuración especifica qué hacer con los recursos solicitados. por ejemplo, se podría decir que todo lo enviado a / cargará archivos desde el área /srv/httpdocs/ del disco duro local, excepto /cgi-bin/ que ejecutará un programa ubicado en /cgi-bin/, y cualquier cosa bajo /scripts / y que termina en .pl será ejecutado por el intérprete PERL.
Los detalles específicos varían según la configuración del servidor web, por lo que no existe un estándar universal que le indique al cliente web si se puede garantizar que recibirá una copia de una página estática o el resultado de un programa que se ejecuta. Todo lo que el cliente web puede esperar es que si solicita un recurso, el servidor web le responda.
Respuesta2
El servidor web nosabercualquiera de esos significados: en todos los casos simplemente recibe la ruta del recurso, la ejecuta a través del programa principal del sitio web y le envía el resultado resultante. Y, por supuesto, diferentes programas hacen cosas diferentes según el camino que se les ha asignado.
Si no hay ningún programa configurado busca un archivo con ese nombre y lo sirve directamente. (PHP y CGI suelen estar en algún punto intermedio: el servidor web todavía busca un archivo, pero luego lo ejecutasí mismocomo el programa.)
Entonces, lo único /node/43que la convierte en una "vista Drupal" es que el servidor web se ha configurado para pasar /node/<anything>al software Drupal. La página web todavía se considera un recurso, aunque se haya generado dinámicamente.
(El propio Drupal, por supuesto, sabe que si la ruta comienza con /node/ella, será seguida por el ID de vista).
Las solicitudes REST también son solicitudes de recursos completamente regulares; lo que los hace "RESTful" es simplemente el estilo y el comportamiento generales. (Por ejemplo, las URL con el estilo de /book/345se ajustan a la ideología REST, mientras /api/get_book?id=345que no).