La pregunta es un poco circular (es decir, realmente se pregunta por qué la URL, o parte de ella, es visible en la URL). Y así, la respuesta corta es que es necesario por definición. La respuesta mucho más larga sigue …
Puede ver la definición de una URL, como el Identificador uniforme de recursos (URI): sintaxis genérica, y realmente no hay una cosa separada que sea URL + datos, sino que la URL es una entidad que incluye todos sus datos.
Una URL genérica es:
esquema: // autoridad / ruta? consulta # fragmento
- ¿Existe alguna posibilidad de que se cierre Internet / World Wide Web? ¿Cómo sería el mundo?
- Al comprar en línea en China, ¿hay algún otro sitio web de habla inglesa aparte de Alibaba y DX? ¿Por qué todos venden las mismas cosas?
- ¿Cómo se puede explicar el funcionamiento de la red mundial en términos simples?
- ¿Fue la creación de la especificación de solicitud Http Xml el pivote más importante para la web?
- ¿Qué impacto social causó la invención de la red mundial?
El esquema en cuestión en un HTTP get es http. HTTP define de manera similar los componentes en el Protocolo de transferencia de hipertexto – HTTP / 1.1.
La autoridad de la URL genérica es la parte del host en HTTP (incluyendo IP versus dns, números de puerto, información del usuario, etc.).
La parte de la ruta son datos jerárquicos que ayudan a identificar el recurso con el que está interactuando.
La parte de la consulta son datos no jerárquicos que ayudan a identificar el recurso con el que está interactuando.
Tanto la ruta (por ejemplo, /cgi-bin/script.cgi o / search) como la consulta (id = 12 & name = michael o q = i + need + to + search + something & biw = 2560 & bih = 1499 & source = lnms & tbm = isch & sa = X & ei = GcEwVcmgFsb7oQSZpIH4Ag & ved = 0CAYQ_AUoAQ) son intrínsecamente parte de la URL.
Tenga en cuenta que solo son visibles si la URL en sí es visible. Y si la URL es visible, son visibles. También tenga en cuenta que para los servidores en el medio, si usa https en lugar de http, tanto la ruta como la consulta no son visibles. Sin embargo, si cualquiera de los lados de la conexión (o ambos) está dejando caer la URL en los registros o mostrándola en la barra de direcciones o lo que sea, entonces esa URL completa está expuesta, incluidos los datos que pueda contener.
Tenga en cuenta también que, incluso cuando realiza un verbo HTTP diferente (POST, PUT, DELETE), todavía puede tener partes de ruta y consulta en la URL, y estos pueden ser “datos”. La URL de solicitud aún especifica el recurso con el que interactúa, y todas las partes están permitidas. Dentro de la POST generalmente hay un tipo de medio (a veces llamado tipo MIME o tipo de contenido) que define el formato del contenido que se publica. Ese tipo de medio no tiene que ser nombres de parámetros. Podría POSTAR un archivo, por ejemplo, en su tipo de medio nativo.
Uno de los tipos de medios más comunes es application / x-www-form-urlencoded. Este tipo de medio particular está registrado en Page en iana.org y especificado en HTML5. Este es el tipo de medio predeterminado para la publicación de un elemento de formulario en HTML, y hace los parámetros de nombre = valor a los que otros se refieren. Otro tipo de medio bastante común es multipart / form-data que también tiene una parte de nombre y valor, aunque el formato de este es diferente.
Pero incluso en un formulario HTML, puede hacer que el atributo de acción del formulario sea algo así como action = “http://www.example.org/secret/data/id/script?password=42&ssn=123456789” (probablemente con el & escapó a & amp; ya que es parte del documento HTML, pero se entiende la idea). Luego, si su formulario HTML tenía elementos de entrada con nombres de tarjeta de crédito y ccv2 y estos se completaron para enviar, y el formulario tenía método = “post”, entonces la tarjeta de crédito = 00000 & ccv2 = 123 estaría en el cuerpo POST, pero la contraseña = 42 & ssn = 123456789, así como el secreto / datos / id / script seguirían formando parte de la URL.
Un HTTP GET no tiene un cuerpo (técnicamente podría tener un cuerpo, pero no puede usarlo de ninguna manera para afectar la semántica de la solicitud, por lo que devolvería el mismo recurso sin importar el contenido del cuerpo. Es raro y mejor ignorar esto y pensar GET == no body). Cuando está haciendo un GET, todo lo que está haciendo es recuperar información de una entidad devuelta de un recurso. Entonces, todo lo que necesita hacer es proporcionar los datos jerárquicos (ruta) y los datos no jerárquicos (parámetro de consulta) para identificar el recurso en cuestión, luego obtiene la entidad. Entonces, en HTML, si su formulario tiene method = “get” (que también es el método predeterminado), sus elementos de entrada se convierten en parámetros de consulta de URL (porque HTML lo dice). Y tenga en cuenta que, como anteriormente, podría tener algunos parámetros de consulta en la acción (como contraseña y ssn) y algunos de los tipos de entrada (como tarjeta de crédito y ccv2), pero el algoritmo HTML5 sobrescribe la consulta para que sea solo la de los elementos del formulario , por lo que la contraseña y el SSN desaparecerían en este caso. Pero esto lo dicta HTML5, no ninguna de las especificaciones para HTTP o HTTP GET o URL.
Para completar, todo lo anterior también puede verse influenciado por la parte del fragmento de una URL, y también puede tener fragmentos como parte de la URL HTTP GET o HTTP POST, y estos fragmentos podrían tener datos como parte de ellos. El propósito de la parte del fragmento es identificar un recurso secundario, a través del recurso primario que está a la izquierda del símbolo #. Este recurso secundario es a menudo un subconjunto (como un ancla en HTML), pero también puede ser una vista o una representación diferente. Lo que define cómo lidiar con el fragmento no es en realidad el esquema (por lo que HTTP no lo define como un subconjunto de la URL), sino que lo define el tipo de medio del recurso devuelto. Hay más detalles sobre esto en las especificaciones vinculadas anteriormente.
