Usiamo per il nostro esempio il sito www.brescianet.com.
Prima di tutto identifichiamo l'indirizzo IP del sito www.brescianet.com.
In una finestra DOS digitiamo il comando ping www.brescianet.com e analizziamo la risposta.

L'IP che cerchiamo è quindi: 62.149.130.28. Apriamo adesso Internet Explorer e digitiamo sulla barra degli indirizzi http://62.149.130.28 . Il browser dovrebbe visualizzare la pagina in figura indicante lo status del server "multisito" [un solo IP n domini] che ospita "www.brescianet.com"

Apriamo adesso una finestra DOS e digitiamo:

Telnet 62.149.130.28 80

La finestra a questo punto si pulisce.
Digitiamo quindi (rispettando il maiuscolo e il minuscolo):

GET / HTTP/1.1

e battiamo invio (a video non si vede il testo che abbiamo battuto!). Scriviamo poi:
 
Host: 62.149.130.28

La sequenza a video rappresenta la risposta [HTTP Response Headers] del WEB server (IIS della microsoft versione 6.0 nel nostro esempio) che eroga le pagine di  www.brescianet.com. Vediamo di analizzare la parte di risposta contenente i tag HTML. Copiamo quindi nel blocco note la sequenza evidenziata in giallo e salviamola nel file pioppo.htm (basta pippo!!!).

Apriamo di seguito il file appena creato con Internet Explorer. Come si può notare si tratta della stessa pagina che si era ricevuta scrivendo l'indirizzo http://62.149.130.28.
In realtà la sequenza di comandi digitata inizialmente corrisponde alla sequenza di comandi [HTTP Request Headers] inviata dal client al Web Server quando l'utente ha richiesto la pagina  http://62.149.130.28.

Vdiamo un esempio analogo di HTTP Request mediante Telnet. Rispetto al precedente differisce solo per aver sostituito, nell'header tag Host, l'indirizzo IP reale con il nome effettivo del sito. La pagina HTML ricevuta questa volta corrisponde alla vera homepage del sito www.brescianet.com. Questo esempio evidenzia come il provider di brescianet.com (Aruba) riesce a gestire con un unico IP più siti sulla stessa macchina: sfrutta l'header Host per capire la pagina da inviare al client.

Vediamo ora di analizzare il significato delle operazioni appena condotte. La comunicazione tra server e client HTTP è basata sullo scambio di messaggi testuali tipicamente indicati come HTTP Request e HTTP Response. All'interno di questi due tipi di comandi abbiamo gli HTTP headers che sono delle informazioni addizionali che accompagnano sia le richieste HTTP che le risposte HTTP.

Gli HTTP headers forniscono importanti informazioni per la navigazione. Per esempio l'HTTP header permette al browser di conoscere la lunghezza e il tipo relativi ai documenti da visualizzare. Permettono inoltre la gestione dell'accesso, mediante login (user e password), alle pagine sicure

Alcune informazioni che possono essere trovate negli HTTP headers sono evidenziate in seguito:

- User authentication
- Data type
- Data length
- Cookies

HTTP Request Headers

Gli HTTP request headers sono spediti come parte di una HTTP Request. Questi headers definiscono in dettaglio la richiesta da fare al Web server. Abbiamo la GET request che è composta interamente da headers mentre la POST request contiene un blocco extra di dati, posti immediatamente dopo gli headers, che contengono gli argomenti postati nel form.

Esempio: HTTP request headers corrispondente all'URL http://www.brescianet.com/pioppo/conta.php

GET /pioppo/conta.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://www.brescianet.com/pioppo/
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.brescianet.com
Connection: Keep-Alive

In dettaglio le HTTP request sono composte da due parti:
- la prima linea che identifica il tipo di richiesta (GET, POST, HEAD [vedi pag.24 del rcf2616] ) e la versione HTTP utilizzata
- le linee successive contenenti gli headers veri e propri la cui struttura può differire leggermente a seconda del tipo di richiesta. Queste linee sono suddivise in due parti mediante i "due punti :".

Gli headers sono seguiti da una linea bianca. Se l'HTTP request è un POST, a qualsiasi dato postato segue una linea bianca. Qualora non vi siano dati postati, come ad esempio nelle GET Request, la linea bianca è comunque richiesta.

Ad ogni HTTP Request prodotta da un Browser dovrebbe corrispondere sempre una HTTP Response redatta dal WEB Server.

HTTP Response Headers

Quando un WEB server risponde a una HTTP Request, spedisce al client un HTTP Response Headers. L'HTTP Response Headers è molto simile all'HTTP request headers

Esempio di HTTP Response Headers

HTTP/1.1 200 OK
Date: Sun, 02 Jul 2006 22:28:58 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Last-Modified: Sat, 29 Jan 2005 04:13:19 GMT
ETag: "824319-509-c6d5c0"
Accept-Ranges: bytes
Content-Length: 1289
Connection: close
Content-Type: text/html

La prima linea è delimitata mediante lo spazio. e contiene lo status della risposta e la versione HTTP utilizzata. Lo status code 200 indica che la richiesta è OK e non si è verificato alcun errore. Un altro valore possibile potrebbe essere 404 (page not found) che corrisponde al non aver trovato sul Web Server la pagina richiesta.

Gli errori sono raggruppati in base alla cifra corrispondente alle centinaia ed esattamente:

1xx: Informativa - la richiesta è stata ricevuta ed è possibile continuare il processo
        100: Continue
        101: Switching Protocols
2xx: OK - la richiesta è stata ricevuta, elaborata e accettata
        200: OK
        201: Created
        202: Accepted
        203: Non-Authoritative Information
        204: No Content
        205: Reset Content
        206: Partial Content
        207: Multi-Status
3xx: Ridirezione - ulteriori azioni devono essere intraprese al fine di concludere la richiesta
        300: Multiple Choices
        301: Moved Permanently
               This and all future requests should be directed to another URL.
        302: Found
                This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945)
                required the client to perform temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented it
                as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, majority of
                Web applications and frameworks still use the 302 status code as if it were the 303.
        303: See Other (since HTTP/1.1)
                The response to the request can be found under another URL using a GET method.
        304: Not Modified
        305: Use Proxy (since HTTP/1.1)
                Many HTTP clients (such as Mozilla and Internet Explorer) don't correctly handle responses with this status code.
        306 is no longer used, but reserved. Was used for 'Switch Proxy'.
        307: Temporary Redirect (since HTTP/1.1)
4xx: Errore sul Client: la richiesta contiene degli errori sintattici oppure non può essere completata per qualche motivo
        400: Bad Request
        401: Unauthorized
               Similar to 403/Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. See basic authentication scheme and digest access authentication.
        402: Payment Required
               The original intention was that this code might be used as part of some form of digital cash/micropayment scheme, but that has never eventuated, and thus this code has never been used.
        403: Forbidden
        404: Not Found
        405: Method Not Allowed
        406: Not Acceptable
        407: Proxy Authentication Required
        408: Request Timeout
        409: Conflict
        410: Gone
        411: Length Required
        412: Precondition Failed
        413: Request Entity Too Large
        414: Request-URL Too Long
        415: Unsupported Media Type
        416: Requested Range Not Satisfiable
        417: Expectation Failed
        449: Retry With
5xx; Errore sul Server: il server fallisce nell'esaudire la richiesta nonostante la richiesta sia corretta nella forma.
        500: Internal Server Error
        501: Not Implemented
        502: Bad Gateway
        503: Service Unavailable
        504: Gateway Timeout
        505: HTTP Version Not Supported
        509: Bandwidth Limit Exceeded
 
Dopo la parte relativa agli header, dopo una linea bianca, seguono i dati relativi alla pagina richiesta e che nell'esempio hanno una lunghezza di 1.289 bytes come indicato negli headers tag: Accept-Ranges e Content-Length.