La primera tarea de una aplicacion de web scraping es la de recuperar documentos que contienen informacion para ser extraida. Para los sitios webs que constan de varias paginas o que requieren la mantencion de la sesion entre solicitudes o informacion de autenticacion, un cierto nivel de ingieneria inversa es a menudo necesaria para desarrollar una aplicacion web de web scraping correspondiente. Este tipo de exploracion requiere un buen conocimiento del protocolo de transferencia de hipertexto o HTTP el protocolo que da poder a la internet.
HTTP es un protocolo de solicitud/respuesta concebido como un protocolo de comunicaciones entre clientes y servidor web. Los clientes son programas o scripts que envian peticiones a los servidores, algunos ejemplo de clientes se incluyen los navegadores, tal como firefox, internet explorer o crawlers, como los utilizados por Yahoo!, Google y web scrapers.
Siempre que su navegador web obtiene un archivo (una pagina, una foto, etc) de un servidor web, lo hace utilizando HTTP. Esa solicitud que su ordenador envia al servidor web contiene todo tipo de informacion interesante. HTTP define metodos (aveces denominados verbs) para indicar la accion deseada a realizar por el servidor web en el recurso solicitado. Lo que este recurso representa, ya sea datos o datos preexistentes que son generados dinamicamente, depende de la aplicacion del servidor. A menudo, el recurso corresponde a un archivo o salida de un ejecutable que reside en el servidor. Una peticion HTTP consta de un metodo de peticion, un URL de solicitud, los campos de cabecera, y un cuerpo.
HTTP 1.1 define los siguientes metodos de peticion, de los cuales solo dos metodos de peticion seran de interes para nosotros - GET y POST.
GET: Recupera el recurso identificado por la URL de la solicitud.
HEAD: Devuelve las cabeceras identificadas por la URL de la solicitud.
POST: Envia los datos de longitud ilimitada en el servidor web.
PUT: Almacena un recurso bajo el URL de la solicitud.
DELETE: Elimina el recurso identificado por la URL de la solicitud.
OPTIONS: Devuelve los metodos HTTP que soporta el servidor.
TRACE: Devuelve los campos de cabecera que han sido enviados con la peticion TRACE.
Peticiones GET
Comencemos con una simple peticion HTTP GET, una pagina que devuelva el index ficticio del tal pagina:
el sitio es - ejemplo.com. La siguiente es la peticion que su navegador envia al servidor para recuperar el archivo index:
GET /index.html HTTP 1.1
Host: www.ejemplo.com
Los componentes individuales de la solicitud anterior se detallan a continuacion:
GET es el metodo o la operacion que debe aplicarse sobre el recurso del servidor. Piense en ello como un verbo en una frase, una accion que desea realizar en algo.
index.html es el identificador uniforme de recursos o URI. Proporciona un punto unico de referencia para el recurso, el objeto o destino de la operacion.
HTTP 1.1 especifica la version del protocolo HTTP en uso por el cliente.
El metodo, URI, y la especificacion HTTP juntos conforman la linea de peticion.
En un unico encabezado Host y su valor asociado www.ejemplo.com siguen la linea de la peticion.
Mas pares de cabecera : Valor pueden seguir.
Basado en el recurso, el valor de la cabecera Host y el protocolo en uso http://www.ejemplo.com/index, Es la url completa del recurso solicitado resultante.
La mayoria de las solicitudes de las cabeceras de los sitios son sin embargo mas complejas que contienen muchos campos adicionales.
Puede utilizar herramientas como Firebug, Live HTTP Headers Plugin de firefox, para comprobar las cabeceras que son enviadas por el navegador y las respuestas correspondientes recibidas desde el servidor. Un encabezado que ha sido capturado con Live HTTP Headers para el sitio yahoo.com se muestra a continuacion. Como se puede ver hay muchos campos adicionales junto con la accion GET.
GET /?p=us HTTP/1.1
Host: in.yahoo.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: B=1mjov258ke&b=4&d=g2uJ6p15tCRXz. (truncated)
Cache-Control: max-age=0
Cadenas de consulta
Otra disposicion de URL es un mecanismo que se llama cadena de consulta (query string), que se utiliza para pasar parametros de la peticion a aplicaciones web. A continuacion se muestra una peticion GET que incluye una cadena de consulta se utiliza para solicitar una determinada pagina de ejemplo.com.
GET /index.php?page=3&limit=10
Host: ejemplo.com
Hay algunos puntos notables que tenemos que tomar en cuenta en la URL:
Un signo de interrogacion indica el final de la ruta del recurso y de ahi comienza la cadena de consulta.
La cadena de consulta se compone de pares clave-valor, donde cada pareja esta separada por un signo (&).
Las claves y los valores estan separados por un signo igual. Las cadenas de consulta no son especificas de operaciones GET y pueden ser utilizadas en otras operaciones como POST, que miraremos a continuacion.
Peticiones POST
La adicion del metodo POST es quizas una de las mas grandes mejoras del HTTP especificadas hasta la fecha. Este metodo puede ser acreditado con la transicion de la web para una verdadera plataforma de desarrollo de aplicaciones web interactivas.
Cuando se utiliza un navegador web como cliente, esto mas a menudo se utiliza en formularios HTML. Si un formulario HTML especifica un metodo POST, el navegador enviara los datos de los campos del formulario en una peticion POST en lugar de una peticion GET.
Una gran diferencia entre una solicitud GET y una solicitud POST es que el POST incluye un cuerpo siguiendo los encabezados de solicitud para contener los datos que se presentaran. POST pretende añadir o modificar los datos expuestos por la aplicacion, un resultado posible es que se crea un nuevo recurso o se cambia un recurso existente.
Sintaxis de URL
La URL proporciona un medio de localizar cualquier recurso de internet, pero estos recursos pueden accederse por diferentes esquemas (Por ejemplo: HTTP, FTP, SMTP), y la sintaxis de la URL varia de esquema a esquema. A pesar de las diferencias entre varios esquemas, las URLS se adhieren a una sintaxis general de URL, y existe una superposicion significativa en el estilo y la sintaxis entre distintos esquemas de URL.
Todos los mensajes HTTP, con la posible excepcion del contenido del mensjae, utilizan el conjunto de caracteres ISO-8859-1 (ISO-Latin). Una solicitud HTTP puede incluir un encabezado de peticion Accept-Encoding que identifica codificaciones de caracteres alternativos que no sean aceptables para el contenido de la respuesta HTTP. La mayoria de los esquemas HTTP basan su sintaxis en este formato general de nueve partes:
<scheme>://<user>:<pass>@<host>:<port>/<path>?<query>#<frag>
La mayoria de las URLs no contienen todos estos componentes. Las tres partes mas importantes de una URL son scheme, host y path (esquema, servidor y ruta). Las distintas partes se explican a continuacion.
+------------+-----------------------------------------------------------------------+----------------------+ | Componente | Descripcion | Valor por defecto | +------------+-----------------------------------------------------------------------+----------------------+ | scheme | Protocolo utilizado para a obtener un recurso | Ninguno | +------------+-----------------------------------------------------------------------+----------------------+ | user | El nombre de usuario, algunos scheme requieren | anonymous | | | acceso anonimo para acceder a un recurso | | +------------+-----------------------------------------------------------------------+----------------------+ | pass | La contraseña se puede incluir despues del nombre | <correo electronico> | | | de usuario, separados por dos puntos(:) | | +------------+-----------------------------------------------------------------------+----------------------+ | host | El nombre del servidor o direccion IP que aloja | Ninguno | | | el recurso | | +------------+-----------------------------------------------------------------------+----------------------+ | port | El numero de puerto en el que el servidor que aloja | Especifico al scheme | | | el recurso esta escuchando. Muchos schemes tienen | | | | numeros de puerto por defecto (el numero de puerto | | | | predeterminado para HTTP es el 80) | | +------------+-----------------------------------------------------------------------+----------------------+ | path | El nombre local para el recurso en el servidor, separado | Ninguno | | | por los componentes de la URL anteriores por una | | | | barra (/), la sintaxis del componente path es servidor y | | | | especifico al scheme. | | +------------+-----------------------------------------------------------------------+----------------------+ | query | Utilizado por algunos schemes para pasar parametros a | Ninguno | | | las aplicaciones activas (como base de datos, bulletin boards, | | | | motores de busqueda y otros portales de internet). No hay | | | | un formato comun para el contenido del componente de query. | | | | Esta separado por el resto de la URL por el caracter "?". | | +------------+-----------------------------------------------------------------------+----------------------+ | frag | Un nombre para una pieza o parte del recurso. El campo frag | | | | no se pasa al servidor cuando hace referencia al objeto; es utilizado | Ninguno | | | internamente por el cliente. Esta separado del resto de la URL | | | | por el caracter "#". | | +------------+-----------------------------------------------------------------------+----------------------+
Gestion de estados HTTP y Cookies
La tarea principal de un servidor web es satisfacer cada solicitud HTTP recibida del cliente. Todo lo que el servidor web considera al generar la respuesta HTTP esta incluido en la peticion. Si dos clientes web completamente diferentes envian solicitudes HTTP identicas al mismo servidor web, el servidor web usara el mismo metodo para generar la respuesta, que puede incluir la ejecucion de algunas aplicaciones del lado del servidor.
Los sitios webs modernos sin embargo tienen que proporcionar un toque personal a los clientes. Ellos quieren saber mas acerca de los usuarios sobre los otros extremos de las conexiones y poder hacer un seguimiento de los usuarios mientras navegan. Las transacciones HTTP son sin estado. Cada peticion/respuesta ocurre en el aislamiento. Muchos sitios web quieren construir un estado gradual a medida que interactuan con el sitio (por ejemplo, llenar un carrito de compras en linea). Para ello, los sitios webs necesitan una manera de distinguir una transaccion HTTP de otra.
Las cookies son la mejor manera de identificar los diferentes usuarios y permitir sesiones persistentes. Las cookies se desarrollaron por primera vez por Netscape pero ahora son compatibles con todos los navegadores principales. Puede clasificar las cookies generalmente en dos tipos: las cookies de sesion y las cookies persistentes. Una cookie de sesion es una cookie temporal que mantiene un registro de configuracion y las preferencias de como un usuario navega en el sitio. Una cookie de sesion se elimina cuando el usuario cierra el navegador. Las cookies persistentes pueden vivir mas tiempo; se almacenan en el disco y sobreviven despues de salir del navegador e incluso reiniciar el equipo. Las cookies persistentes a menudo se utilizan para mantener un perfil de configuracion o un nombre de usuario para un sitio que un usuario visita periodicamente. La unica diferencia entre las cookies de sesion y las cookies persistentes es cuando caducan.
Ahora que hemos tenido un breve resumen de HTTP, podemos proceder a lo que vamos - web scraping.! En la proxima parte.
No hay comentarios:
Publicar un comentario