UD4 Servicio Web (WWW)

UD4 Servicio web (WWW)
UD4 Manejo del protocolo http.

Funcionamiento y estructura.
Descripción de peticiones o request methods.
Códigos de estado.
Cabeceras.
Codificación del contenido. Páginas de códigos.
Realización de peticiones HTTP en Internet mediante un proxy, livehttpheaders
o método similar, analizando el protocolo utilizado.
FUNCIONAMIENTO Y ESTRUCTURA DEL PROTOCOLO HTTP

Para comenzar esta Unidad didáctica, voy a explicar en qué consiste el protocolo http.
Como hemos visto, el modelo TCP/Ip cuenta con diversos protocolos en su capa de aplicación, entre ellos alguno
de los más importantes son los protocolos HTTP y HTTPS.
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol), es un sencillo protocolo con

arquitectura cliente-servidor que articula los intercambios de información entre los clientes web y los
servidores HTTP. La versión más actual es la 1.1 definido en el RFC 2616.
DESCRIPCION DE PETICIONES O REQUEST METHODS

El dialogo con los servidores HTTP se establece a través de mensajes formados por líneas de
texto, cada una de las cuales contiene los diferentes comandos y opciones de protocolo. Solo
existen dos tipos de mensajes: uno para realizar peticiones y otro para devolver la
correspondiente respuesta.
pág. 1
La estructura general de los dos tipos de mensajes se puede ver en el siguiente esquema:
La primera línea del mensaje de solicitud contiene el comando que se solicita al servidor HTTP,
mientras que la primera línea de respuesta contiene el resultado de la operación identificado por
un código numérico que permite conocer el éxito o fracaso de dicha operación.
La separación entre cada línea del mensaje se realiza con un par de cR-LF (retornos de carro) . El
final de las cabeceras se indica con una línea en blanco.
Como ejemplo se muestran los mensajes intercambiados por cliente y servidor cuand o
accedemos a la dirección http://portal.us.es con el navegador Mozilla Firefox. Cada color de
fondo se identifica con la estructura de los mensajes anteriormente explicada.
pág. 2
El protocolo HTTP consta de los siguientes comandos:
GET: Sirve para recoger cualquier tipo de información del servidor. Se utiliza siempre que se pulsa
sobre un enlace o se teclea directamente una URL (Uniform Resource Locator).
HEAD: Es un comando similar a GET pero que pide solamente la cabecera del objeto. Lo utilizan
principalmente los gestores de cachés de páginas o los servidores proxy para conocer cuándo es
necesario actualizar la copia que se mantiene de un fichero.
pág. 3
POST: Este comando envía datos de información al servidor, normalmente procedente de un

formulario web, para que el servidor los administre o los añada a una base de datos.
PUT: Almacena un objeto en la URL especificada. Si la dirección de destino ya contenía un objeto,

se considera que se está enviando una versión actualizada del mismo.
DELETE: Elimina el objeto especificado. Este comando es muy poco utilizado.
TRACE: Realiza un eco de la solicitud recibida para que el cliente pueda conocer qué servidores
intermedios están añadiendo información o modificando la petición.
OPTIONS: Devielve los métodos HTTP que soporta el cliente. Se suele utilizar para comprobar las
funcionalidad de un servidor web.
CONNECT: Se utiliza en los servidores proxy que puedan establecer un túnel directamente (SSL)
LOS CÓDIGOS DE ESTADO

1xx: Respuestas informativas
Petición recibida, continuando proceso. Esta respuesta significa que el servidor ha recibido los encabezados de
la petición, y que el cliente debería proceder a enviar el cuerpo de la misma (en el caso de peticiones para las
cuales el cuerpo necesita ser enviado; por ejemplo, una petición Hypertext Transfer Protocol). Si el cue rpo de la
petición es largo, es ineficiente enviarlo a un servidor, cuando la petición ha sido ya rechazada, debido a
encabezados inapropiados. Para hacer que un servidor cheque si la petición podría ser aceptada basada
únicamente en los encabezados de la petición, el cliente debe enviar Expect: 100-continue como un encabezado
en su petición inicial (vea Plantilla:Web-RFC: Expect header) y verificar si un código de estado 100
Continue es recibido en respuesta, antes de continuar (o recibir 417 Expectation Failed y no continuar).1 100
- Continue
El navegador puede continuar realizando su petición (se utiliza para indicar que la primera parte de la
petición del navegador se ha recibido correctamente ).2
101 - Switching Protocols
El servidor acepta el cambio de protocolo propuesto por el navegador (puede ser por ejemplo un cambio
HTTP 1.0 a HTTP 1.1 de ).
102 - Processing (WebDAV - RFC 2518)
El servidor está procesando la petición del navegador pero todavía no ha terminado (esto evita que el
navegador piense que la petición se ha perdido cuando no recibe ninguna respuesta). 2 103 -
Checkpoint
Se va a reanudar una petición POST o PUT que fue abortada previamente.
pág. 4
2xx: Peticiones correctas

Esta clase de código de estado indica que la petición fue recibida correctamente, entendida y aceptada.
200 - OK
Respuesta estándar para peticiones correctas.
201 - Created
La petición ha sido completada y ha resultado en la creación de un nuevo recurso.
202 - Accepted
La petición ha sido aceptada para procesamiento, pero este no ha sido completado. La petición eventualmente
pudiere no ser satisfecha, ya que podría ser no permitida o prohibida cuando el procesamiento tenga lugar.
203 - Non-Authoritative Information (desde HTTP/1.1)
La petición se ha completado con éxito, pero su contenido no se ha obtenido de la fuente originalmente solicitada
sino de otro servidor.2
204 - No Content
La petición se ha completado con éxito pero su respuesta no tiene ningún contenido (la respuesta sí que puede
incluir información en sus cabeceras HTTP).2
205 - Reset Content
La petición se ha completado con éxito, pero su respuesta no tiene contenidos y además, el navegador tiene
que inicializar la página desde la que se realizó la petición (este código es útil por ejemplo para páginas con
formularios cuyo contenido debe borrarse después de que el usuario lo envíe). 2
206 - Partial Content
La petición servirá parcialmente el contenido solicitado. Esta característica es utilizada por herramientas de
descarga como wget para continuar la transferencia de descargas anteriormente interrumpidas, o para dividir
una descarga y procesar las partes simultáneamente.
207 - Multi-Status (Multi-Status, WebDAV)
El cuerpo del mensaje que sigue es un mensaje XML y puede contener algún número de códigos de respuesta
separados, dependiendo de cuántas sub-peticiones sean hechas.
pág. 5
208 Already Reported (WebDAV)
El listado de elementos DAV ya se notificó previamente, por lo que no se van a volver a listar. 2
3xx: Redirecciones
El cliente tiene que tomar una acción adicional para completar la petición.
Esta clase de código de estado indica que una acción subsecuente necesita efectuarse por el agente de usuario
para completar la petición. La acción requerida puede ser llevada a cabo por el agente de usuario sin interacción
con el usuario si y solo si el método utilizado en la segunda petición es GET o HEAD. El agente de usuario no
debe redirigir automáticamente una petición más de 5 veces, dado que tal funcionamiento indica usualmente
un Bucle infinito.
300 - Multiple Choices
Indica opciones múltiples para el URI que el cliente podría seguir. Esto podría ser utilizado, por ejemplo, para
presentar distintas opciones de formato para video, listar archivos con distintas extensiones o word sense
disambiguation.
301 - Moved Permanently
Esta y todas las peticiones futuras deberían ser dirigidas a la URI dada.
302 - Found
Este es el código de redirección más popular, pero también un ejemplo de las prácticas de la industria
contradiciendo el estándar. La especificación HTTP/1.0 (RFC 1945) requería que el cliente realizara una
redirección temporal (la frase descriptiva original fue "Moved Temporarily"), pero los navegadores populares lo
implementaron como 303 See Other. Por tanto, HTTP/1.1 añadió códigos de estado 303 y 307 para eliminar la
ambigüedad entre ambos comportamientos. Sin embargo, la mayoría de aplicaciones web y bibliotecas de
desarrollo aún utilizan el código de respuesta 302 como si fuera el 303.
303 - See Other (desde HTTP/1.1)
La respuesta a la petición puede ser encontrada bajo otra URI utilizando el método GET.
304 - Not Modified
Indica que la petición a la URL no ha sido modificada desde que fue requerida por última vez. Típicamente, el
cliente HTTP provee un encabezado como If-Modified-Since para indicar una fecha y hora contra la cual el
servidor pueda comparar. El uso de este encabezado ahorra ancho de banda y reprocesamiento tanto del
servidor como del cliente.
305 - Use Proxy (desde HTTP/1.1)
Muchos clientes HTTP (como Mozilla e Internet Explorer) no se apegan al estándar al procesar respuestas con
este código, principalmente por motivos de seguridad.
306 - Switch Proxy
Este código se utilizaba en las versiones antiguas de HTTP pero ya no se usa (aunque está reservado para usos
futuros).
307 Temporary Redirect (desde HTTP/1.1)
Se trata de una redirección que debería haber sido hecha con otra URI, sin embargo, aún puede ser procesada
con la URI proporcionada. En contraste con el código 303, el método de la petición no debería ser cambiado
cuando el cliente repita la solicitud. Por ejemplo, una solicitud POST tiene que ser repetida utilizando otra
petición POST.
308 - Permanent Redirect
El recurso solicitado por el navegador se encuentra en otro lugar y este cambio es permanente. A diferencia del
código 301, no se permite cambiar el método HTTP para la nueva petición (así por ejemplo, si envías un formulario
a un recurso que ha cambiado de lugar, todo seguirá funcionando bien). 2
4xx Errores del cliente
El error 404 en Wikipedia
La solicitud contiene sintaxis incorrecta o no puede procesarse.
La intención de la clase de códigos de respuesta 4xx es para casos en los cuales el cliente parece haber errado la
petición. Excepto cuando se responde a una petición HEAD, el servidor debe incluir una entidad que contenga
una explicación a la situación de error, y si es una condición temporal o permanente. Estos códigos de estado son
aplicables a cualquier método de solicitud (como GET o POST). Los agentes de usuario deben desplegar cualquier
entidad al usuario. Estos son típicamente los códigos de respuesta de error más comúnmente encontrados.
400 - Bad Request
La solicitud contiene sintaxis errónea y no debería repetirse.

401 - Unauthorized
Similar al 403 Forbidden, pero específicamente para su uso cuando la autentificación es posible pero ha fallado o
aún no ha sido provista. Vea autenticación HTTP básica y Digest access authentication.
402 Payment Required
La intención original era que este código pudiese ser usado como parte de alguna forma o esquema d e Dinero
electrónico o micropagos, pero eso no sucedió, y este código nunca se utilizó.
403 - Forbidden
La solicitud fue legal, pero el servidor rehúsa responderla dado que el cliente no tiene los privilegios para hacerla.
En contraste a una respuesta 401 No autorizado, la autenticación no haría la diferencia.
404 - Not Found
Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la página o recurso solicitado.
405 - Method Not Allowed
Una petición fue hecha a una URI utilizando un método de solicitud no soportado por dicha URI; por ejemplo,
cuando se utiliza GET en un formulario que requiere que los datos sean presentados vía POST, o utilizando PUT
en un recurso de solo lectura.
406 - Not Acceptable
El servidor no es capaz de devolver los datos en ninguno de los formatos aceptados por el cliente, indicados por
éste en la cabecera "Accept" de la petición.
407 - Proxy Authentication Required
408 - Request Timeout
El cliente falló al continuar la petición - excepto durante la ejecución de videos Adobe Flash cuando solo significa
que el usuario cerró la ventana de video o se movió a otro. ref
409 - Conflict
Indica que la solicitud no pudo ser procesada debido a un conflicto con el estado actual del recurso que esta
identifica.
410 - Gone
Indica que el recurso solicitado ya no está disponible y no lo estará de nuevo. Debería ser utilizado cuando un
recurso ha sido quitado de forma permanente.
Si un cliente recibe este código no debería volver a solicitar el recurso en el futuro. Por ejemplo, un buscador lo
eliminará de sus índices y lo hará más rápidamente que utilizando un código 404.
411 - Length Required
El servidor rechaza la petición del navegador porque no incluye la cabecera Content-Length adecuada.
412 - Precondition Failed
El servidor no es capaz de cumplir con algunas de las condiciones impuestas por el navegador en su petición.
413 Request Entity Too Large
La petición del navegador es demasiado grande y por ese motivo el servidor no la procesa 2
414 - Request-URI Too Long
La URI de la petición del navegador es demasiado grande y por ese motivo el servidor no la procesa (esta
condición se produce en muy raras ocasiones y casi siempre porque el navegador envía como GET una petición
que debería ser POST).
415 - Unsupported Media Type
La petición del navegador tiene un formato que no entiende el servidor y por eso no se procesa. 2
416 - Requested Range Not Satisfiable
El cliente ha preguntado por una parte de un archivo, pero el servidor no puede proporcionar esa parte, por
ejemplo, si el cliente preguntó por una parte de un archivo que está más allá de los límites del fin del archivo.
417 - Expectation Failed
La petición del navegador no se procesa porque el servidor no es capaz de cumplir con los requerimientos de la
cabecera Expect de la petición.2
418 - I'm a teapot
Soy una tetera.
422 - Unprocessable Entity (WebDAV - RFC 4918)
La solicitud está bien formada pero fue imposible seguirla debido a errores semánticos.
423 - Locked (WebDAV - RFC 4918)
El recurso al que se está teniendo acceso está bloqueado.
424 - Failed Dependency (WebDAV) (RFC 4918)
La solicitud falló debido a una falla en la solicitud previa.
425 - Unassigned
Definido en los drafts de WebDav Advanced Collections, pero no está presente en "Web Distributed Authoring
and Versioning (WebDAV) Ordered Collections Protocol" (RFC 3648).
426 - Upgrade Required (RFC 7231)
El cliente debería cambiarse a TLS/1.0.
428 - Precondition Required
El servidor requiere que la petición del navegador sea condicional (este tipo de peticiones evitan los problemas
producidos al modificar con PUT un recurso que ha sido modificado por otra parte).
429 Too Many Requests
Hay muchas conexiones desde esta dirección de internet.
431 Request Header Fileds Too Large)
El servidor no puede procesar la petición porque una de las cabeceras de la petición es demasiado grande. Este
error también se produce cuando la suma del tamaño de todas las peticiones es demasiado grande.
449
Una extensión de Microsoft: La petición debería ser reintentada después de hacer la acción apropiada.
451 - Unavailable for Legal Reasons
El contenido ha sido eliminado como consecuencia de una orden judicial o sentencia emitida por un tribunal.
5xx Errores de servidor

El servidor falló al completar una solicitud aparentemente válida.
Los códigos de respuesta que comienzan con el dígito "5" indican casos en los cuales el servidor tiene
registrado aún antes de servir la solicitud, que está errado o es incapaz de ejecutar la petición. Excepto cuando
está respondiendo a un método HEAD, el servidor debe incluir una entidad que contenga una explicación de la
situación de error, y si es una condición temporal o permanente. Los agentes de usuario deben desplegar
cualquier entidad incluida al usuario. Estos códigos de respuesta son aplicables a cualquier método de
petición.
500 - Internal Server Error
Es un código comúnmente emitido por aplicaciones empotradas en servidores web, mismas que generan
contenido dinámicamente, por ejemplo aplicaciones montadas en IIS o Tomcat, cuando se encuentran con
situaciones de error ajenas a la naturaleza del servidor web.
501 Not Implemented
El servidor no soporta alguna funcionalidad necesaria para responder a la solicitud del navegador (como por
ejemplo el método utilizado para la petición).
502 - Bad Gateway
El servidor está actuando de proxy o gateway y ha recibido una respuesta inválida del otro servidor, por lo que
no puede responder adecuadamente a la petición del navegador.
503 - Service Unavailable
El servidor no puede responder a la petición del navegador porque está congestionado o está realizando tareas
de mantenimiento.
504 - Gateway Timeout
El servidor está actuando de proxy o gateway y no ha recibido a tiempo una respuesta del otro servidor, por lo
que no puede responder adecuadamente a la petición del navegador.
505 - HTTP Version Not Supported
El servidor no soporta o no quiere soportar la versión del protocolo HTTP utilizada en la petición del navegador.
506 - Variant Also Negotiates (RFC 2295)
El servidor ha detectado una referencia circular al procesar la parte de la negociación del contenido de la petición.
507 - Insufficient Storage (WebDAV - RFC 4918)
El servidor no puede crear o modificar el recurso solicitado porque no hay suficiente espacio de almacenamiento
libre.2
508 - Loop Detected (WebDAV)
La petición no se puede procesar porque el servidor ha encontrado un bucle infinito al intentar procesarla. 2
509 - Bandwidth Limit Exceeded
Límite de ancho de banda excedido. Este código de estatus, a pesar de ser utilizado por muchos servidores, no es
oficial.
510 - Not Extended (RFC 2774)
La petición del navegador debe añadir más extensiones para que el servidor pueda pr ocesarla.2
511 - Network Authentication Required
El navegador debe autenticarse para poder realizar peticiones (se utiliza por ejemplo con los portales cautivos
que te obligan a autenticarte antes de empezar a navegar).
CABECERAS
Existen tres tipos de cabeceras:
Cabeceras generales: Que se aplican tanto a las peticiones como a las respuestas, pero no al contenido de los
mensajes.
Cabeceras de petición: Permiten al cliente pasar información adicional al servidor sobre la petición y el propio
cliente.
Cabeceras de respuesta: Que permiten al servidor pasar información adicional al cliente sobre la respuesta, el
propio servidor y el recurso solicitado.
CABECERAS GENERALES
• Cache-Control: Es el campo de cabecera que se usa para especificar directivas que deben obedecer
todos los mecanismos de caché para las peticiones y las respuestas. Configura el comportamiento que
debe tener el agente de usuario y servidor origen respecto a la petición o respuesta en la caché.
• Connection: Este campo permite al emisor especificar opciones que son deseadas para una conexión
particular. Entre sus opciones, se encuentra keep-alive, que permite conexiones persistentes y close,
que provoca el cierre de la conexión para cada mensaje.
• Date: Es un campo que especifica la fecha y la hora en la que el mensaje fue generado. Los servidores
de origen deben incluir esta cabecera en todas las respuestas, excepto en los siguientes casos:
o Si el estado de la respuesta es 100 o 101 o Si el estado de la respuesta es un
error, como 500 o 503
o Si el servidor no tiene un reloj que pueda proporcionar una aproximación

razonable del tiempo actual.
13
UD1 Conceptos básicos de sistemas de servidores.
Sonia Fernández Sapena
• Pragma: Este campo es usado para incluir directivas especificas de implementación que quizás se
aplican a algún mensaje a lo largo del canal.
Transfer-Encoding: Es el campo que especifica el tipo de codificación que se ha realizado sobre el cuerpo
del mensaje para una transferencia segura entre el emisor y el receptor.
• Upgrade: Permite especificar cual es el protocolo de comunicación adicional que soporta el cliente y
recomendaría usar si el servidor encuentra apropiado cambiar el protocolo.
• Via: Es usado por pasarelas y proxys para indicar los protocolos intermedios y recipientes entre el agente
usuario y el servidor, sobre las peticiones y entre el servidor origen y el cliente, sobre las respuestas.
CABECERAS DE PETICION
Las cabeceras de petición son utilizadas por los agente de usuario para enviar informacion adicional al servidor.
• Accept: Es usado para especificar ciertos tipos media que son aceptables por la respuesta.
• Accept-charset: Puede ser usado para indicar qué conjunto de caracteres son aceptables para la
respuesta.
• Accept-encoding: Este campo es similar a Accept pero restringido a los "content-codings" que son
aceptables en la respuesta.
• Accept_Language: Indica el conjunto de lenguajes naturales que son preferidos como respuesta de una
petición.
• Authorization: Cuando un agente de usuario desea autentificarse con el servidor, después de haber
recibido una respuesta de código 401
• From: Este campo debería contener la dirección de email del usuario que controla el agente de usuario.
La interpretación de este campo es que la petición está siendo ejecutada en nombre de una persona.
• Host: Especifica el host y el número de puerto del recurso que está siendo solicitado. Esto permite al
servidor origen o pasarela diferencial entre varias URL.
• If-Modified-Since: Este campo es uno de los que se utilizan para realizar peticiones condicionales. En
este caso, el método de petición provocara una respuesta del servidor únicamente cuando se haya
modificado el recurso solicitado después del momento solicitado.
• If-Unmodified-Since: Este campo tiene el comportamiento contrario al anterior. El método de petición

provocará una respuesta del servidor origen solamente cuando el recurso solicitado no se haya
modificado dende el momento especificado en este campo.
• If-Match: En este caso, la respuesta del servidor origen debe contener alguna entidad cuya etiqueta
corresponda con algún valor de etiquetas definido en este campo.
• If-None-Match: Este campo tiene el comportamiento contrario al anterior.
14
• If- Range: Este campo sirve para solicitar una copia parcial de un recurso. Se especifica cual es el rango
del recurso que se solicita
Max-Forwards: Este campo proporciona un mecanismo con los métodos TRACE Y OPTIONS para
limitar el número de pasarelas que reenviaran la petición. Este campo se suele utilizar para trazar
peticiones y encontrar bucles de reenvíos en la red.
• Proxy-Authorization: Este campo permite al cliente identificarse a un proxy que requiera autenticación.
El valor de este campo consiste en credenciales que contienen la información de autenticación del
usuario del agente para el recurso que está siendo solicitado.
• Range: En este campo se especifica uno o varios rangos para una petición parcial de un recurso.
• User-Agent: Contiene información acerca del agente de usuario que origina la petición. Tiene propósitos
estadísticos, aunque en la actualidad se ha intensificado su uso para determinar el dispositivo que realiza
la petición y, de esta manera, enviar una respuesta con las limitaciones adecuadas.
CABECERAS DE RESPUESTA
Las cabeceras de respuesta son utilizadas por los servidores web para enviar información adicional al agente de
usuario.
• Age: Este campo transmite una estimación de la cantidad de tiempo desde que se generó la respuesta
en el servidor origen:
• Location: Es un campo que es usado para redirigir al receptor a la localización especificada.
• Proxy-Authenticate: Es el campo que indica al agente de usuario que debe autentificarse, y lo indica
enviando el esquema y los parámetros aplicados para la petición del recurso.
15
• Retry-after: Es usado con una respuesta 503 (Server Unavailable) para indicar cuanto tiempo se espera
que el servicio no esté disponible para las peticiones del cliente.
• Server: Contiene información acerca del software que es usado por el servidor.
Warning: Es usado para transmitir información adicional sobre el estado o transformación de un

mensaje que quizás no se ha reflejado en el mensaje.
• Www-Authenticate: Debe ser incluido en las respuestas con código 401 (No autorizado). El valor de este
campo consiste en al menos una referencia que indica el esquema de autenticación y parámetros
aplicables a la petición URI.
CABECERAS DE ENTIDAD
Aportan información sobre el contenido del mensaje o, si no hay contenido, sobre el recurso al que hace
referencia la URL de la petición
• Allow: Este campo contine una lista de los métodos soportados aplicables al recurso especificado. El
propósito de este campo es estrictamente informar al receptor de los métodos válidos asociados con el
recurso.
• Content-Base: Indica la URI base para resolver las URI relativas
• Content- Encoding: Este campo es usado como un modificador de un tipo de medio. Cuando está
presente, su valor indica que se ha realizado una codificación y el tipo de esta. Por lo tanto hace falta un
mecanismo de decodificación.
• Content-Language: Este campo especifica el lenguaje natural de la audiciencia ala que se destina la
entidad adjunta.
• Content-Length: Especifica el tamaño del cuerpo entidad, en números decimales de octetos, que se
envia.
• Content-Location: Es usado para suministrar la localización del recurso para la entidad adjuntada en el
mensaje cuando esa entidad es accesible desde una localización distinta del recurso URI de la petición.
• Content-MD5: Este campo contiene un MD6 del cuerpo entidad con el propósito de proporcionar
integridad de la transmisión del mensaje.
• Content-Range: Es enviado con un cuerpo de entidad parcial para especificar en qué parte del cuerpo
de entidad total debe ser aplicado.
• Content-Type: Este campo indica el tipo de medio que es enviado en el cuerpo de la entidad al cliente
o, en el caso de una petició HEAD, el tipo de medio que sería enviado si la petición fuera un GET.
• Etag: Define una marca para todo el contenido asociado
• Expires: Indica la fecha a partir de la cual la respuesta deja de ser válida
16
• Last-Modified: Indica la fecha de la última modificación.
17
Instalación y configuración del software de Servidor Web
UF1271
CODIFICACION DEL CONTENIDO

En la cabecera Accept, determina el tipo de contenido o MIME que se espera de la respuesta. Su valor debe ser
una cadena MIME.
La codificación que es usada en la transmisión de mensaje por el protocolo HTTP es US -ASCII de 7 bits. Sin
embargo, si se desea transmitir un objeto o recurso binario, no se puede usar esta representación. Aquí entra
en juego el estandar MIME (Multipurpose Internet Mail Extensions). Los MIME son especificaciones dirigidas al
intercambio de todo tipo de archivos, evitando la manipulación interna de estos parte del usuario para una
correcta transmisión.
Para que se transmitan los recursos MIME es necesario especificar el tipo de recurso en el campo de cabecera
"Content-Type". Esto permitira que el cliente trate adecuadamente los datos que se proporcionan la respuesta.
Los principales métodos de codificación son:
• Gzip : Es una abreviatura de GNU ZIP, que es un algoritmo de compresión basada en el algoritmo
matemático Deflate.
• Delate: Algoritmo de compresión de menor utilización que gzip
• Sdch: el menos estandarizado de todos los anteriores.
18
Instalación y configuración del software de Servidor Web
UF1271
19

UD4 Servicio Web (WWW)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UD4 Servicio Web (WWW)

Cargado por

Copyright:

Formatos disponibles

UD4 Servicio web (WWW)

UD4 Manejo del protocolo http.

FUNCIONAMIENTO Y ESTRUCTURA DEL PROTOCOLO HTTP

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol), es un sencillo protocolo con

DESCRIPCION DE PETICIONES O REQUEST METHODS

El protocolo HTTP consta de los siguientes comandos:

POST: Este comando envía datos de información al servidor, normalmente procedente de un

PUT: Almacena un objeto en la URL especificada. Si la dirección de destino ya contenía un objeto,

DELETE: Elimina el objeto especificado. Este comando es muy poco utilizado.

LOS CÓDIGOS DE ESTADO

101 - Switching Protocols

102 - Processing (WebDAV - RFC 2518)

Se va a reanudar una petición POST o PUT que fue abortada previamente.

2xx: Peticiones correctas

Respuesta estándar para peticiones correctas.

La petición ha sido completada y ha resultado en la creación de un nuevo recurso.

203 - Non-Authoritative Information (desde HTTP/1.1)

205 - Reset Content

206 - Partial Content

207 - Multi-Status (Multi-Status, WebDAV)

208 Already Reported (WebDAV)

300 - Multiple Choices

301 - Moved Permanently

303 - See Other (desde HTTP/1.1)

304 - Not Modified

305 - Use Proxy (desde HTTP/1.1)

306 - Switch Proxy

307 Temporary Redirect (desde HTTP/1.1)

308 - Permanent Redirect

4xx Errores del cliente

El error 404 en Wikipedia

La solicitud contiene sintaxis incorrecta o no puede procesarse.

400 - Bad Request

La solicitud contiene sintaxis errónea y no debería repetirse.

402 Payment Required

404 - Not Found

405 - Method Not Allowed

406 - Not Acceptable

407 - Proxy Authentication Required

408 - Request Timeout

411 - Length Required

412 - Precondition Failed

413 Request Entity Too Large

414 - Request-URI Too Long

415 - Unsupported Media Type

416 - Requested Range Not Satisfiable

417 - Expectation Failed

418 - I'm a teapot

Soy una tetera.

422 - Unprocessable Entity (WebDAV - RFC 4918)

423 - Locked (WebDAV - RFC 4918)

El recurso al que se está teniendo acceso está bloqueado.

424 - Failed Dependency (WebDAV) (RFC 4918)

La solicitud falló debido a una falla en la solicitud previa.

426 - Upgrade Required (RFC 7231)

El cliente debería cambiarse a TLS/1.0.

428 - Precondition Required

429 Too Many Requests

Hay muchas conexiones desde esta dirección de internet.

431 Request Header Fileds Too Large)

451 - Unavailable for Legal Reasons

5xx Errores de servidor

500 - Internal Server Error