.. _http-method:

Métodos
=======
|HTTP| tiene `un buen puñado de métodos
<https://es.wikipedia.org/wiki/Protocolo_de_transferencia_de_hipertexto#Métodos_de_petición>`_
y no es propósito de este epígrafe glosarlos todos. La sintaxis de la línea que
expresa el método de petición es la siguiente::

   MÉTODO RECURSO HTTP/VERSIÓN

Una primera serie de métodos son los siguientes:

**GET**
   Pide al servidor un recurso. Por ejemplo::

      GET /images/diagrama.png HTTP/1.1

   que pretende obtener del servidor un recurso llamado :file:`diagrama.png`
   dentro del directorio :file:`/images`.

   El método no permite enviar un cuerpo en la petición, por lo que si se desean
   enviar datos se integran en la |URL| como parámetros::

      GET /form.php?nombre=Juan&edad=25

**HEAD**
   Funciona como **GET**, pero en la respuesta el servidor sólo envía las
   cabeceras y no el cuerpo con el recurso. Es útil cuando se desean consultar
   sólo los metadatos. Ejemplo::

      HEAD /images/diagrama.png HTTP/1.1

**POST**
   Pide un recurso enviando datos al servidor en el cuerpo de la petición. Por
   ejemplo::

      POST /form.php
      Host: www.example.net
      ... Otras cabeceras ...

      nombre=Juan&edad=25

**CONNECT**
   Este método permite el establecimiento de túneles |HTTP|, de manera que se
   establece una conexión |HTTP| entre el cliente y el proxy, y una vez
   establecida, el proxy permite una comunicación |TCP| entre el cliente y
   un servidor final\ [#]_. en la que se limita a hacer pasar el tráfico a
   través de él sin modificiación alguna.

   .. note:: Este método es el que se suele usar para establecer comunicaciones
      |HTTP|\ s, mediando un proxy |HTTP|: el cliente establece una conexión
      *CONNECT* con el proxy::

         CONNECT www.example.com:443 HTTP/1.1

      lo que originará que el proxy abra una conexión al puerto 443 con el
      servidor final y retransmita *byte* a *byte* lo que le envía el cliente,
      que es una comunicación |HTTP|\ s que, al estar cifrada, es incapaz de
      entender.

   .. seealso:: Lea `esta respuesta de overflow
      <https://stackoverflow.com/a/40329026>`_, que es muy elocuente.

**OPTIONS**
   Informa de los métodos que soporta el servidor *web*::

      $ telnet www.example.net 80
      OPTIONS / HTTP/1.1
      Host: www.example.net

      HTTP/1.1 200 OK
      Server: Microsoft-IIS/5.0
      Date: Tue, 22 Oct 2016 09:10:20 GMT
      Connection: close
      Allow: GET, HEAD, POST, TRACE, OPTIONS
      Content-Length: 0

   No todos los servidores pueden aceptarlos o permitirlos.

**TRACE**
   Es un método de "*ping*": devuelve como respuesta los campos de cabecera que
   recibe el servidor. Por tanto, recibiremos los mismos campos que enviamos más
   los que hayan podido añadir los proxies intermedios::

      $ telnet www.example.net 80
      TRACE / HTTP/1.1
      Host: www.example.net

      HTTP/1.1 200 OK
      Server: Microsoft-IIS/5.0
      Date: Tue, 22 Oct 2016 09:10:20 GMT
      Connection: close
      Content-Type: message/http
      Content-Length: 40

      TRACE / HTTP/1.1
      Host: www.example.net

  .. note:: Lo habitual es que los servidores *web* no soporten o no permitan
     estos dos últimos métodos, por proporcionar información a los atacantes. 

.. _metodos-webdav:

Además de los métodos anteriores, |HTTP| define otra serie de métodos
relacionados con `WebDAV <https://es.wikipedia.org/wiki/WebDAV>`_ para hacer de
la |WWW| no sólo un medio legible, sino también editable. Por ello, son métodos
que permiten modificar directamente los recursos del servidor: **PUT** (subir
ficheros), **MKCOL** (crear directorios), **DELETE** (borrar ficheros),
**PROPFIND** (ver el contenido de directorios), etc. Son métodos, por tanto, que
permitirían añadir al servidor web funcionalidades de servidor |FTP|.

.. note:: A partir de HTTP/1.1 es legal enviar en la línea de petición la |URL|
   completa y no sólo la dirección al recurso. Por tanto, esto es perfectamente
   posible::

      GET http://www.example.net/images/diagrama.png HTTP/1.1

.. rubric:: Notas al pie

.. [#] Este método permitiría implementar usa solución para tunelizar :ref:`SSH sobre
   HTTPs <haproxy>`, pero como :ref:`nginx <n-ginx>` no lo soporta (no al menos
   de serie) es preciso otro software como el propuesto :program:`haproxy`.

.. |URL| replace:: :abbr:`URL (Uniform Resource Locator)`
.. |WWW| replace:: :abbr:`WWW (World Wide Web)`
.. |TCP| replace:: :abbr:`TCP (Transmission Control Protocol)`