Diferencia entre revisiones de «HTTP/Mensajes/Peticiones/Encabezados de solicitud HTTP (HTTP request headers)»

Contenido eliminado Contenido añadido
Sin resumen de edición
Página creada con «Ya hemos hablado sobre otras peticiones y los métodos HTTP GET y POST pero hay más en un mensaje de solicitud HTTP que solo el método. Un mensaje de HTTP completo consis...»
Etiqueta: editor de código 2017
Línea 1:
Ya hemos hablado sobre otras peticiones y los métodos HTTP GET y POST pero hay masmás en un mensaje de solicitud HTTP que solo el método. Un mensaje de HTTP completo consiste de las siguientes partes:
 
* [metodo]   [URL]   [versión]
Ya hemos hablado sobre otras peticiones y los métodos HTTP GET y POST pero hay mas en un mensaje de solicitud HTTP que solo el método. Un mensaje de HTTP completo consiste de las siguientes partes:
* [encabezados]
 
* [cuerpo]
[metodo]  [URL]  [versión]
 
[encabezados]
 
[cuerpo]
 
El mensaje siempre está en ASCII y la línea de inicio contiene el método, la URL y la versión HTTP (comúnmente 1.1, que ha existido desde 1999). Por último en la sección del cuerpo puede contener información como los datos de inicio de sesión de una cuenta como lo vimos en capítulos anteriores. Al cargar un archivo, la sección del cuerpo puede ser bastante grande.
 
En la parte central, en la cual vemos el Hosthost: google.com   contiene uno o mas encabezados HTTP (recordemos que, en HTTP 1.1 el host es un encabezado requerido). En los encabezados podemos encontrar mucha información que nos va ser útil para procesar una petición. Por ejemplo, en el capítulo uno, habíamos hablado sobre representaciones de recursos y comocómo el cliente y el servidor pueden negociar de la mejor manera (negociación de contenido). AcontinuaciònA continuación veremos un ejemplo donde ilustramos cómo quedan los encabezados si el cliente quisiera ver un contenido en francés.
 
 
{| class="wikitable"
|-
Línea 21 ⟶ 14:
Accept-Language: fr-FR
|}
 
 
Hay numerosos encabezados definidos en las especificaciones del HTTP. Algunos de estos pueden aparecer tanto en una solicitud como en una respuesta. El mejor ejemplo para representar este caso es el encabezado de la fecha. El cliente o el servidor pueden la fecha en la que se creó el mensaje.
Línea 36 ⟶ 28:
|}
 
Los encabezados no son obligatorios a excepción del de host que siempre debe aparecer, pero cuando se incluyen encabezados estos deben cumplir con los estándares establecidos , en el caso de la fecha dice que es un HTTP-date que debe estar en formato <nowiki>RFC 822</nowiki>
 
Acontinuaciòn veremos una tabla con los encabezados màsmás usados
Los encabezados no son obligatorios a excepción del de host que siempre debe aparecer, pero cuando se incluyen encabezados estos deben cumplir con los estándares establecidos , en el caso de la fecha dice que es un HTTP-date que debe estar en formato <nowiki>RFC 822</nowiki>
 
Acontinuaciòn veremos una tabla con los encabezados màs usados
{| class="wikitable"
|Encabezado
Línea 52 ⟶ 43:
|-
|User-Agent
|Información sobre el usuario (el software) que realiza la solicitud. Muchos
 
Muchas aplicaciones utilizan la información contenida en esta cabecera, cuando está presente, por ejemplo para averiguar qué navegador está realizando la petición (Internet Explorer 6, Internet Explorer, Chrome, Firefox, etc.).
|<nowiki>- User-Agent: <producto> / <versión-producto> <comentario></nowiki>
 
<nowiki>*</nowiki>comentario puede no tener nada o tener más informaciòninformación de subproductos
|User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
|-
|Accept
|Describe los tipos de contenidos que el usuario está dispuesto a aceptar. Esta cabecera es utilizadoutilizada para la negociación de contenido.
|<nowiki>- Accept: <MIME_type>/<MIME_subtype></nowiki>
 
Línea 81 ⟶ 72:
|-
|Cookie
|Contiene información de las cookies. (Se veràverá en el capítulo posterior) contiene información que generalmente ayuda al servidor a rastrear o identificar un usuario.
|<nowiki>- Cookie: <cookie-list></nowiki>
 
Línea 92 ⟶ 83:
 
Since
|Contendrá la fecha de cuando el usuario realizó la última petición (en la memoria caché) del recurso. El servidor sólo tiene que enviar ala todoparte el recurso si ha sido modificadomodificada desde entonces.
|<nowiki>- If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT</nowiki>
|If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
Línea 124 ⟶ 115:
Cache-Control: no-cache
|}
Nótese la aparición de "q" en algunas de las cabeceras. El valor de q es siempre un número de 0 a 1 y representa el valor de la calidad o "grado relativo de preferencia" por un valor particular. El valor por defecto es 1.0, y números más altos indican una mayor preferencia.
 
* [[Formularios y Peticiones GET]]
 
* [[Sobre los métodos y los recursos]]
nótese la aparición de "q" en algunas de las cabeceras. El valor de q es siempre un número de
* [[Encabezados de Petición]]
 
0 a 1 y representa el valor de la calidad o "grado relativo de preferencia" por un valor particular.
 
El valor por defecto es 1.0, y números más altos indican una mayor preferencia.
 
 
 
[[Formularios y Peticiones GET]]
[[Sobre los métodos y los recursos]]
[[Encabezados de Petición]]