L'Hypertext Transfert Protocol è un protocollo dello strato di applicazione implementato tra un server ed un client che parlano tra loro scambiandosi messaggi HTTP; HTTP come ogni altro protocollo di rete definisce la struttura di questi messaggi ed il modo con il quale questi ultimi vengono scambiati. Ogni pagina web può essere concepita come un insieme di oggetti ( immagini, file html, video, file audio etc..) ognuno di essi indirizzabili con un singolo URL contenente l'indirizzo del server e il nome del percorso per raggiungere gli oggetti.

Ad esempio:

www.antoniodimaio.com/image/immagine.gif

www.antoniodimaio.com è l'host name mentre /image/immagine.gif il percorso dell'immagine. Un browser è un agente dell'utente per il Web che implementa il lato client di HTTP in grado di mostrare la pagina Web richiesta fornendo anche altre funzionalità per semplificare la navigazione. Un server web memorizza gli oggetti Web, ciascuno indirizzabile da un URL; questi ultimi implementano il lato server del protocollo HTTP; quando un utente richiede una pagina web il browser invia messaggi di richiesta all'HTTP per gli oggetti nella pagina server. HTTP utilizza TCP come protocollo di trasporto garantendo un trasferimento affidabile dei dati; Http non deve quindi occuparsi dei dati persi, o dei dettagli sul modo in cui il TCP ritrova o riordina i dati entro la rete.

Un messaggio di richiesta HTTP assume la seguente sintassi:

GET /cartella/pagina.html

HTTP/1.1 Host: www.antoniodimaio.com

Connection: Close

User-agent:

Mozilla Accept-language: it (ritorno carrello)

Il testo del messaggio è scritto in ASCII normale ed è costituito in questo esempio da cinque linee ciascuna separata da un ritorno carrello. La prima linea è detta linea di richiesta le seguenti di intestazione (header line). Ogni linea di richiesta ha tre campi : il campo metodo, il campo URL e il campo versione. Il campo metodo può assumere molti diversi valori, compresi GET, POST e HEAD. Il primo è usato per richiede oggetti al server HTTP. La linea host specifica l'host sul quale l'oggetto risiede mentre il successivo il tipo di connessione ( permanente o non permanente). Le ultime due sono abbastanza esplicative.

Un ipotetico messaggi di risposta ha  la seguente forma:

HTTP/1.1 200 OK

Connection: close

Date: Thu, 23 Aug 2003 11:30:44 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 11 Jun 2003 9:44:22 GMT

Content-Length: 6821

Content-Type text/html

dati,dati,dati....

Il messaggio è suddiviso in tre parti: una linea iniziale di stato sei linee di intestazione e un corpo dell'entità nucleo del messaggio. La linea di stato ha tre campi come il messaggio di richiesta con la versione del protocollo, un codice di stato e un corrispondente messaggio di stato. Ad esempio in questo caso il trasferimento è avvenuto correttamente dal server al browser (codice 200). La nuova linea di intestazione Date rappresenta l'ora e la data del momento in cui la risposta HTTP è stato creata e spedita dal server mentre Last-Modified quella del momento della creazione o dell'ultima modifica dell'oggetto. Conten-Type specifica il tipo di dati del corpo del messaggio.

Come usare il Monitoring Web Page Wizard di NetCrunch 5

Per monitorare pagine web con NetCrunch valorizzare il campo URL e spuntare l'opzione Check Page Header only e Check page presence only dallo strumento Wizard Monitor web. Se in URL viene specificato un nodo non ancora presente nell'atlante quest'ultimo viene aggiunto automaticamente al catalogo.

Al termine della procedura guidata per lo specifico server verrà aggiunto un allarme alla policy a livello di nodo. Tutte le path faranno riferimento alla stessa root. Questo tipo di monitor è consigliabile per server web con siti differenziati in base alla directory virtuale e che hanno la prima parte dell'URL sempre uguale e corrispondente all'indirizzo del server (quindi http://10.0.0.2/sito1, http:/10.0.0.2/sito2 ecc.).

Consiglio di specificare il server web tramite indirizzo IP e di applicare al nodo il metodo di Identificazione basato sull'indirizzo IP.

Altri eventi sono disponibili :

Webpage Download Time (con soglia dinamica) - Authentication faild - Invalid response - Page content have been changed - Page does not exist on server

Come comportarsi in presenza di siti diversificati in base all'Host Header

Alcune organizzazioni potrebbero avere siti in hosting su un solo server con stesso indirizzo IP e porta 80. Ogni sito si differenzia dall'altro mediante host header ( es http://sito1/, http://sito2...); il campo Host di HTTP viene utilizzato per specificare a quale host fa riferimento la risorsa richiesta.

Se un web server supporta il virtual hosting e ospita diversi siti, alla richiesta di una risorsa senza il campo Host dichiarato non saprà come rispondere e restituirà un messaggio di errore, codice 301.

Per cui se si utilizza il Wizard Monitor web page viene creato un nuovo nodo remoto (sprecato perchè è solo un alias dello stesso server).

Creando una nuova service definition, si riescono a monitorare anche i siti con host header ( ad esempio http://mysite dove mysite è definito come record CNAME relativo al record A del server web sul DNS ed host header del sito sul server web stesso).

Questa la "service definition" in NetCrunch:

Protocol TCP/80

Request: Send text data:

GET http://miosito/HTTP/1.1

Host: miosito

Response: Any pattern matches - Pattern text - Start checking from 1 byte of response . Check if response starts with value HTTP/1.1 200 OK