tematcp-ip.docx
TRANSCRIPT
Ichim Cezar Alexandru IB
SCOALA POSTLICEALA „GHEORGHE MARZESCU”
TEMAPROTOCOLUL HTTP
1. PROTOCOLUL HTTP
1.1. TERMINOLOGIE
HTTP - Hypertext Transfer Protocol .World Wide Web este alcătuit din documente care folosesc
un limbaj de formatare denumit HTML, abreviere de la Hypertext Markup Language (limbaj de
marcare prin hipertext). Aceste documente sunt compuse din text de afişat, imagini grafice, comenzi
de formatare şi hiperlegături spre alte documente situate altundeva în Web. Documentele HTML
sunt afişate cel mai frecvent folosind browsere Web, precum Internet Explorer, Safari sau Mozilla
Firefox.
Un protocol denumit Hypertext Transfer Protocol (protocol de transfer prin hipertext)
controlează tranzacţiile dintre un client Web şi un server Web. HTTP este un protocol destinat
stratului aplicaţie. Protocolul HTTP face uz în mod transparent de DNS şi de alte protocoale
Internet pentru a forma conexiuni între clientul şi serverul Web astfel încât utilizatorul cunoaşte
numai numele domeniului şi numele documentului însuşi.
HTTP este, în esenţă, un protocol nesigur. Informaţiile pe suport text sunt transmise „în clar",
între client şi server. Pentru a satisface necesitatea unor reţele Web sigure există alternative precum
Secure HTTP (S-HTTP) sau Secure Sockets Layer (SSL).
Cererile unui client Web către un server Web sunt orientate spre conexiune, deci sunt persistente.
Odată ce clientul a primit conţinutul unei pagini HTML, conexiunea nu mai este activă. Executarea
unui clic în documentul HTML reactivează legătura fie către serverul original (dacă într-acolo
indică hiperlegătura), fie către un alt server, situat altundeva.
Vor fi folosiţi în cele ce urmează următorii termeni:
-conexiune
Un circuit virtual la nivelul transport stabilit între doua programe care doresc sa comunice.
-mesaj
Unitatea de baza a unei comunicații HTTP, constând dintr-o secvență structurata de octeți,
transmisia printr-o conexiune.
-cerere
Un mesaj de cerere HTTP
-răspuns
Un mesaj de răspuns HTTP.
-resursa
Un obiect de date sau serviciu care poate fi identificat de un URI. Resursele pot avea reprezentări
multiple (e.g. formate, mărimi, rezoluții, etc.).
-entitate
Informația transferată într-o operație de cerere sau de răspuns. O entitate cuprinde atât meta-
informații, cât si conținutul propriu-zis.
-reprezentare
O entitate inclusa într-un răspuns ce reprezintă o negociere între client si server.
-negociere
Mecanism de selectare a reprezentării potrivite a unei date solicitate.
-client
Un program care stabilește conexiuni cu scopul de a trimite cereri.
-agent-utilizator
Clientul ce inițiază o cerere (navigator, editor, robot de traversare Web). Navigatoarele cele mai
cunoscute sunt Netscape Navigator, Internet Explorer, Arena, Mozaic.
-Server
O aplicație care accepta conexiuni, răspunzând la anumite cereri transmise de clienți. Un
program poate juca rol atât de server, cât si de client. Un server se poate comporta ca server inițial,
poarta, tunel sau Proxy Web în funcție de natura cererii. Cele mai cunoscute servere Web sunt:
Apache, Netscape Enterprise Server, Sun Web Server, Windows NT Web Server, Stronghold.
-Proxy (intermediar)
Un program intermediar care rulează ca server, cât si drept client pentru a transmite cereri altor
servere. Cererile trimise unui Proxy pot fi rezolvate intern sau transmise mai departe, către alte
servere (posibil translatate). Un proxy trebuie sa implementeze cerințele de server si de client ale
specificației HTTP.
-poarta
Un server care lucrează ca intermediar pentru alte servere, în mod transparent, fiind si un translator
de protocoale.
-tunel
Un program intermediar funcționând ca mijlocitor între doua conexiuni.
-cache
Un depozit local de memorare a mesajelor (datelor) de răspuns si un subsistem de control al
acestuia. Memoria cache reduce timpul de răspuns si congestia rețelei. Orice client si server poate
include un cache.
1.2 STRUCTURA UNUI SERVER WEB SUB LINUX. MODUL DE
FUNCŢIONARE
În figura următoare se va ilustra structura unui server Web sub Linux:
HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un
computer aflat la distanţă spre propriul computer. Dacă se apelează un link sau o adresă de web cum
ar fi http://www.example.com, atunci se cere calculatorului host să afişeze o pagină web
(index.html sau altele). În prima fază numele (adresa) www.example.com este convertit de
protocolul DNS într-o adresă IP. Urmează transferul prin protocolul TCP pe portul standard 80 al
serverului HTTP, ca răspuns la cererea HTTP-GET. Informaţii suplimentare ca de ex. indicaţii
pentru browser, limba dorită ş.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma
cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în
(X)HTML, cu fişiere ataşate ca imagini, fişiere de stil (CSS), scripturi (Javascript), dar pot fi şi
pagini generate dinamic (SSI, JSP, PHP şi ASP.NET). Dacă dintr-un anumit motiv informaţiile nu
pot fi transmise, atunci serverul trimite înapoi un mesaj de eroare. Modul exact de desfăşurare a
acestei acţiuni (cerere şi răspuns) este stabilit în specificaţiile HTTP.
1.3.TRANSFERUL ARGUMENTELOR
Deseori utilizatorul doreşte să transmită informaţii speciale la website. Aici HTTP pune la
dispoziție două posibilităţi:
Transferul datelor în combinaţie cu o cerere pentru o resursă (HTTP-metoda "GET")
Transferul datelor în combinaţie cu o cerere specială (HTTP-metoda "POST")
Datele transferate vin deseori %-codate. La metoda GET se utilizează partea de cerere Uniform
Resource Identifiers (URI) cu simbolul ?. Această metodă se utilizează pentru a transfera o listă de
parametri, pe care partea opusă trebuie să o ia în considerare la prelucrarea cererii.
Deseori această listă cuprinde perechi de valori separate prin semnul &, care sunt alcătuite din
numele parametrului, semnul = şi valoarea parametrului. Rareori se mai utilizează şi semnul ;
pentru separarea înregistrărilor listei .
Exemplu: la pagina de start de la Wikipedia.ro utilizatorul introduce în câmpul de căutare
termenul "pisici", alege categoria "articole" şi apasă butonul de căutare. Atunci browserul trimite
următoarea cerere la server:
GET /wiki/special:Search?search=pisici&go=articol HTTP/1.1 Host: ro.wikipedia.org
...
Serverului Wikipedia îi sunt transmise două perechi de valori: Argument Valoare search pisici
go articol
Perechile de valori se transmit sub forma
Argument1=valoare1&Argument2=valoare2
iar cu ? se ataşează pagina. Astfel serverul află că utilizatorul doreşte să vadă articole despre pisici.
Serverul prelucrează cererea, dar nu trimite un fişier ci redirectează browserul cu un Location-
Header spre pagina dorită:
HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:12:44 GMT
Location: http://ro.wikipedia.org/wiki/pisici
Browserul execută indicaţia şi, pe baza noilor informaţii, emite o nouă cerere: GET /wiki/pisici
HTTP/1.1 Host: ro.wikipedia.org. Serverul răspunde şi oferă pagina cu articole despre pisici:
HTTP/1.0 200 OK Date: Fri, 13 Jan 2008 15:12:48 GMT Last-Modified: Tue,
10 Jan 2008 11:18:20 GMT Content-Language: ro Content-Encoding: gzip Content-
Type: text/html; charset=utf-8 .‹........´ZKs.¹.>Û¿.ž-[¶KÃ!õ²ÌÇlô²¬¬ìuVò*ÉÖ–
3.r`Î+.F”xÊ!ÿ ×.ý.ö´7ý“ü’t.ó"9ÔʛĮ.A.ÐÝ
Partea de date este mai lungă şi de necitit din cauza compresiei gzip. În cazul unei cereri POST
variabilele nu se află în URI, ci în partea body:
POST /wiki/special:Search HTTP/1.1 Host: ro.wikipedia.org Content-Type:
application/x-www-form-urlencoded Content-Length: 24
search=pisici&go=articol
Serverul răspunde astfel:
1.4.ERORI DE HTTP
Erorile de HTTP sunt clasificate în 5 clase (categorii). Acestea sunt (pentru fiecare clasa sunt
date câteva dintre erorile conţinute):
-1xx - erori informaţionale: această clasă a status-ului indică un răspuns provizoriu al
serverului şi conţine numai linia de status (de răspuns) sau alte aplicaţii opţionale. Nu sunt
aplicaţii necesare pentru acestă clasa de răspuns/status. Aceste status-uri pot fi ignorate.
100 - continuă:
Utilizatorul ar trebui să îşi continuie cererea/acţiunea. Acest răspuns provizoriu este folosit
pentru a informa utilizatorul ca partea iniţială a cereri a fost receptată şi că deocamdată nu a fost
refuzată de server. Utilizatorul ar trebui să continuie şi să ignore acest răspuns.
101 - schimbare protocol:
Server-ul înţelege şi are intenţia de a de a îndeplini cererea utilizatorului, răspunând prin această
eroare că părţi ale server-ului sunt în proces de schimbare/mutare. Server-ul va schimba protocolul
imediat după ce răspunsul pentru linia 101 va fi terminată. Protocolul ar trebui schimbat doar în
momentul în care acest lucru este avantajos şi se permite.
-2xx - răspuns reuşit: clasa de răspuns/status ce indică utilizatorului că cererea a fost
primită, înţeleasă şi acceptată cu succes.
200 - ok:
Această cerere a fost executată cu succes. Informaţia a revenit cu un răspuns pozitiv, indiferent
de modul în care s-a făcut cererea.
201 - creat/realizat:
HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:32:43 GMT
Location: http://ro.wikipedia.org/wiki/pisici
Cererea a fost îndeplinită având ca rezultat crearea unui nou rezultat. Noul rezultat poate fi
referit/raportat de către URI-uile înapoiate la intrarea răspunsului.
202 - acceptat:
Cererea a fost acceptata pentru procesare, dar aceasta din urma nu a fost terminată complet.
Scopul acestui mesaj este de a permite unui server să accepte cereri de la alţi utilizatori, fără a cere
conexiunii clientului să insiste până ce procesul/cererea e completă.
203 - informaţie neautorizată:
Informaţia returnată/revenită nu e definitivă ca fiind din server-ul principal, ci e adunată
recepționată de la un server local.
204 - fără conținut:
Server-ul a îndeplinit cererea şi nu e nevoit sa întoarcă răspunsul, dar ar dori să răspundă printr-o
informaţie recentă, gen meta.
205 - conţinut refăcut:
Cererea a fost îndeplinită şi ar trebui ca browser-ul să poată modifica/reseta modul de vizualizare
a documentului ce a cauzat această cerere către server.
206 - conţinut parţial:
Serverul a îndeplinit parţial cererea de primire de la sursă.
-3xx - redirectări: această clasă de răspuns/status indică faptul că acţiunile următoare vor
trebui făcute de browser pentru a putea fi îndeplinită cererea. Cererea ar putea fi direcţionată
de browser fără a interacţiona cu utilizatorul dacă şi numai dacă metoda folosită în cea de a
doua cerere este „Primit/recepţionat” sau „Direcţionat/condus”.
300 - diferite/multiple alegeri:
Sursa cererii corespunde unor seturi de descrieri, fiecare cu locaţii specifice, iar browser-ul dat fiind
negocierea informaţiei, primeşte răspunsul astfel încât utilizatorul/browser-ul să poată alege modul
dorit astfel încât redirectarea să fie spre acea locaţie. În cazul în care cererea a fost de tip
„Condus/trimis”, răspunsul ar trebui să includă o intrare cu lista caracteristicilor şi locaţiilor de unde
utilizatorul sau browser-ul poate alege sursa cea mai apropiată.
301 - modificat/mutat permanent:
Cererii i-a fost atribuite o sursă nouă şi permanentă URI iar cererile următoare ar trebui să
folosească una din sursele returnate URI. Dacă acest mesaj/cod este primit ca răspuns al unei cereri
tip „Primit/recepţionat” sau „Direcţionat/condus”, browser-ul nu trebuie să redirecţioneze automat
cererea, doar dacă nu poate fi confirmată de către utilizator.
302 - găsit:
Sursa cererii este temporar pe un alt URI. În cazul în care redirectarea ar putea fi schimbată
ocazional, utilizatorul ar trebui să folosească în continuare cererea URI (Request-URI) în cazul unor
cereri ulterioare. Dacă mesajul/statusul 302 este recepţionat ca răspuns al unei cereri alta decât
„Primit/recepţionat” sau „Direcţionat/condus”, browser-ul nu trebuie să redirecteze automat cererea
dacă aceasta nu poate fi confirmată de către utilizator.
303 - vezi alta sursă:
Răspunsul cererii poate fi găsit sub un diferit URI şi ar trebui să fie recepţionat folosind metoda
„Primit/recepţionat” de la acea sursă.
304 - nemodificat:
În cazul în care clientul a efectuat o cerere de tip „Primit/recepţionat” şi accesul este permis, dar
documentul nu a fost modificat, serverul ar trebui să răspundă cu acest mesaj/status.
305 - foloseşte proxy:
Cererea trebuie accesată printr-un proxy dat de către câmpul de locaţie. Acesta este dat de către
URI. Beneficiarul va repeta acestă unică cerere prin intermediul unui proxy. Răspunsul 305 va fi
generat doar de către serverul de origine.
306 (nefolosit):
Acest mesaj/status a fost folosit într-o vesiune anterioară a specificaţiilor deci nu mai este folosit,
el fiind reţinut.
307 - redirectare temporară:
Sursa cerută se află temporar la un diferit URI. Din moment ce redirectarea poate fi modificata
ocazional, utilizatorul ar trebui să continue să folosească URI-ul cerut pentru viitoarele acţiuni.
-4xx - erori ale utilizatorilor: această clasă de mesaje/statusuri este folosită în cazurile în
care utilizatorul ar putea greşi formularea cererii. Excepţia fiind răspunsurule pentru cererile
tip „Direcţionat/condus”, atunci serverul ar trebui să conţină o intrare cu o explicaţie a
situaţiei erorii şi dacă e o eroare temporară sau pemanentă. Aceste răspunsuri sunt aplicabile
pentru orice fel de cerere. Browser-ele ar trebui să arate orice intrare cerută de utilizator.
400 - cerere greşită:
Cererea nu a putut fi înţeleasă/percepută de către server din cauza unei sintaxe
greşite/incomplete. Utilizatorul ar trebui să nu repete cererea fără ca aceasta să suporte modificări.
401 - neautorizat:Cererea necesită autentificarea/înregistrarea utilizatorului. Răspunsul
trebuie să includă WWW - câmp de autentificare conţinând o somaţie aplicabilă utilizatorului.
Utilizatorul poate repeta cererea. Dacă cererea deja includea câmpul de autorizare, atunci
răspunsul 401 indică faptul că autorizarea a fost refuzată. Dacă răspunsul 401 conţine aceeaşi
somaţie ca răspuns principal iar browser-ul a executat autentificarea cel puţin o dată, atunci
utilizatorul ar trebui să i se prezinte intrarea dată în răspuns, din moment ce aceasta include
informaţii relevante.
402 - necesită plata:
Rezervat pentru utilizare ulterioară.
403 - interzis:
Serverul a înţeles cererea, dar refuză să o îndeplinească. Autorizarea nu ajută în nici un caz, iar
cererea nu ar mai trebui repetata
404 - negăsit:
Serverul nu a găsit nimic care să corespundă cererii URI. Nu se dau indicaţii despre condiţia
temporară sau permanentă.
405 - metodă nepermisă:
Metoda specificată în linia de cerere (Request-Line) nu este permisă de către sursa identificată
după URI-ul cerut.
406 - neacceptat:
Sursa identificată de cerere este capabilă să genereze doar intrări care au conţinut specific
neacceptat de către condiţiile de acceptare trimise prin cerere.
407 - autentificare prin proxy:
Mesajul este similar celui 401, dar indică situaţia în care utilizatorul trebuie să se autentifice prin
proxy.
408 - cerere expirată:
Utilizatorul nu a făcut cererea în timpul în care serverul era pregătit sa o aştepte. Se poate repeta
cererea fără modificări prealabile.
-5xx - erori de server: răspunsurile/status-urile ce încep cu unitatea/cifra 5 indică cazurile
în care serverul e conştient de greşelile produse sau e incapabil să execute cererea. Excepţie
făcând răspunsul unei cereri „Direcţionat/condus”, serverul ar trebui, în acest caz să includă
o afişare cu o explicaţie a situaţiei de eroare, fie că e temporară sau permanentă.
500 - eroare internă de server:
Server-ul a întâmpinat o condiţie neaşteptată şi o previne spre a putea îndeplini cererea.
501 - neîndeplinit/nerecunoscut:
Server-ul nu poate suporta funcţionalitatea cerută pentru a putea îndeplini cererea. Acesta este
răspunsul specific în cazurile în care server-ul nu recunoaşte metoda de cerere şi nu e capabil să o
suporte indiferent de mijloc/resursă.
502 - poartă/ieşire greşită:
Server-ul, în timp ce încerca să se comporte ca o poartă/ieşire sau ca un proxy, a recepţionat un
răspuns invalid de la un server de deasupra/anterior în încercarea de a îndeplini cererea.
503 - serviciu nedisponibil:
În prezent server-ul nu poate să se ocupe de cererile trimise din cauza unei supraîncărcări sau a
serviciilor de întreţinere a server-ului ce au loc în acel moment. Aceasta este o stare temporară şi în
curând va fi remediată.
504 - poartă/ieşire expirată:
Server-ul, în timp ce încerca să se comporte ca o poartă/ieşire sau ca un proxy, nu a primit un
răspuns la timp de la serverele de deasupra/anterioare lui specificat de URI (ex. HTTP, FTP, LDAP)
sau de la un server auxiliar (ex. DNS) necesar accesării în încercarea de a termina/îndeplini cererea.
505 - versiunea HTTP nu e suportată/susţinută:
Serveru-l nu suportă sau refuză să suporte versiunea de protocol a HTTP ce a fost folosită în
formularea cererii. Server-ul sugerează că e incapabil să completeze/termine cererea folosind
aceeaşi versiune cu cea a clientului.
1.5.VERSIUNI HTTP
1. HTTP/0.9 - prima versiune realizată de Tim Berners-Lee şi echipa sa. Această versiune este
foarte simplă, dar cu numeroase neajunsuri, fiind repede înlocuită de alte versiuni;
2. HTTP/1.0 – versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătăţiri;
3. HTTP/1.1 – versiune de îmbunătăţire şi reparare a neajunsurilor versiunilor anterioare.
În prezent se utilizează două versiuni ale protocolului, HTTP/1.0 şi HTTP/1.1. La versiunea
HTTP/1.0 se stabileşte o nouă conexiune TCP înaintea cererii, iar după transmiterea răspunsului
conexiunea trebuie închisă. Astfel dacă un document HTML cuprinde 10 imagini, vor fi necesare 11
conexiuni TCP, pentru ca pagina să fie afişată complet (în browser). La versiunea 1.1 se pot emite
mai multe cereri şi răspunsuri pe aceeaşi conexiune TCP. Astfel pentru documentul HTML cu 10
imagini este necesară doar o singură conexiune TCP. Deoarece datorită algoritmului Slow-Start
viteza conexiunii TCP este la început mică, dar acum el e necesar doar o singură dată, se scurtează
semnificativ durata totală de încărcare a paginii. La aceasta se adaugă şi faptul că versiunea 1.1
poate relua şi continua transferuri întrerupte.
La HTTP se pierd informaţiile cererilor vechi (deci este un protocol fără reţinerea stării). Prin
utilizarea de cooki-uri în header, se pot realiza însă aplicaţii care pot utiliza informaţii de stare
(opţiunile utilizatorului din sesiunea actuală, coş de cumpărături ş.a.). Chiar şi o recunoaştere a
utilizatorului este astfel posibilă. În mod normal se pot citi informaţiile transmise care parcurg
reţeaua pe computere şi rutere. Prin HTTPS transferul se poate şi cripta.
Versiunea cea mai recentă se poate utiliza în chat-uri prin utilizarea MIME-tip-ului
multipart/replace, care reînnoieşte complet conţinutul ferestrei browser-ului. Noua versiune permite
pe lângă preluarea datelor, şi transmiterea lor la server. Cu ajutorul metodei "PUT" web-designerii
pot să-şi publice paginile web pe webserver prin WebDAV, iar prin metoda "DELETE" ei pot chiar
şi şterge pagini de pe server.
De asemenea, HTTP/1.1 mai oferă metoda "TRACE" prin care se poate urmări calea spre
webserver, şi verifica dacă datele au fost corect transferate. Astfel se poate urmări calea prin diferite
proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicaţie.
1.6 FORMATUL MESAJELOR DE CERERE
Linia de cerere a unui mesaj HTTP este definita astfel:
Request-Line ::= Method Separator Request-URI Separator HTTP-Version
CRLF
Method ::= "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" |
"TRACE"
Request-URI ::= "*" | absolute-URI | abs_path
1.7.DESCRIEREA METODELOR
Serverul va returna codul 405 (Method Not Allowed) sau 501 (Not Implemented) daca se
va trimite numele unei metode inexistente.
Descrierea metodelor permise urmeaza mai jos:
-OPTIONS
ReprezintĂ o cerere de informaţii despre opţiunile de comunicare disponibile într-un dialog
cerere/raspuns.
-GET
Reprezintă o cerere de accesare a unor informaţii (entitati) identificate de Request-URI. Semantica
metodei GET se schimba în cerere conditionată dacă mesajul de cerere include câmpuri antet If-
Modified-Since, If-Match, If-Range. Daca se specifica un câmp Range, atunci GET va specifica
o cerere partială.
-HEAD
Este similară cu GET, dar serverul va returna un mesaj având informatii doar în antetul lui. Meta-
informaţtiile din antetele HTTP din răspunsul la o cerere HEAD vor fi identice cu cele din răspunsul
la o cerere GET. Metoda HEAD este folosită deseori pentru testarea validitaţii, accesibilitaţii si
modificărilor recente ale unei legaturi hipertext. Pentru documente HTML, o cerere HEAD va avea ca
răspuns doar antetul paginii, adică informaţiile cuprinse între marcatorii <head>...</head>.
-POST
Metoda e utilizată să identifice dacă serverul acceptă o entitate înglobată în cadrul cererii. POST
este proiectată să implementeze o metodă uniformă pentru funcţtiile: adnotarea resurselor,
trimiterea unui mesaj într-o listă de ştiri, trimiterea datelor unui formular Web, extinderea unei baze
de date printr-o operaţiune de adăugare. Semantica exactă a metodei este definită de server.
Răspunsul serverului poate fi 200 (OK), 201 (Created) sau 204 (No Content).
-PUT
Specifică faptul că o entitate inclusă în mesaj sa fie stocată la adresa dată de Request-URI. Dacă
resursa deja există, se consideră o actualizare a ei. Diferenţa fundamentală între PUT si POST este
reflectată de modul diferit de manipulare a adresei REquest-URI. Într-o cerere POST, URI identifica
resursa care va prelucra entitatea înglobată de mesaj. Acea resursă poate fi un proces de prelucrare a
datelor, o poartă către alt protocol, o entitate separată acceptând adnotări. Prin contrast, URI dintr-
un PUT identifică entitatea inclusă în mesajul de cerere. O unica resursa poate fi identificată de URI-
uri multiple.
-DELETE
Cere ca serverul să şteargă resursa identificată de Request-URI.
-TRACE
Invocă o cerere de diagnosticare (trasaj).
1.7.EXEMPLU DE HTTP
Cererea clientului:
GET / HTTP/1.1
Host: www.example.com
Răspunsul serverului:
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html