HTTP-hoder brukes til å utveksle tjenesteinformasjon mellom klienten og serveren. Denne informasjonen forblir usynlig for brukerne, men uten den er det umulig riktig arbeid nettleser. Til vanlige brukere Informasjonen om dette og hensikten med http-headers vil virke ganske kompleks, men den inneholder faktisk ikke vanskelige formuleringer. Dette er noe en nettbruker møter hver dag.

overskrifter?

"Hypertext Transfer Protocol" er nøyaktig hvordan det oversettes. Takket være dets eksistens er klient-server-kommunikasjon mulig. Hvis du forklarer med enkle ord, sender nettleserbrukeren en forespørsel, og starter en tilkobling til serveren. Sistnevnte venter som standard på en forespørsel fra klienten, behandler den og sender tilbake den endelige informasjonen eller svaret. I søkelinje brukeren «kjører inn» nettsideadressen som begynner med http:// og mottar resultatet i form av en side som åpnes.

Når nettstedsadressen er skrevet inn på riktig linje, finner nettleseren den nødvendige serveren ved hjelp av DNS. Serveren gjenkjenner http-headeren (en eller flere) som klienten sender til den, og utsteder deretter den nødvendige headeren. Settet med påkrevde består av allerede eksisterende overskrifter og de som ikke ble funnet.

Generelt er http-overskrifter ganske effektive. De er ikke synlige i HTML-kodingen; de sendes før den forespurte informasjonen. Mange overskrifter sendes automatisk av serveren. For å sende den til PHP språk, bør du bruke overskriftsfunksjonen.

Interaksjon mellom nettleser og nettside

Samspillet mellom nettleseren og nettstedet er ganske enkelt. Så http-overskriften starter forespørselslinjen, som deretter sendes til serveren. Svaret kommer behov for klienten informasjon. http-protokollen har forresten vært den mest brukte på internett i sytten år. Det er enkelt, pålitelig, raskt og fleksibelt. hovedoppgaven http - be om informasjon fra en webserver. Klienten er nettleseren, og serveren er ligthttp, apache, nginx. Hvis forbindelsen mellom dem var vellykket, mottar serveren nødvendig informasjon som svar på forespørselen. http-informasjon inneholder tekst, lydfiler, video.

Protokollen kan være en transport for andre. Kundens forespørsel består av tre deler:

• startlinje (meldingstype);
• overskrifter (meldingsparametere);
• informasjonstekst (en melding atskilt med en tom linje).

Startlinjen er et obligatorisk element i forespørselen om http-hodefelt. Strukturen til en brukerforespørsel består av tre hoveddeler:

1. Metode. Den brukes til å angi typen forespørsel.
2. Sti. Dette er URL-strengen som følger domenet.
3. Protokoll brukt. Den består av en protokoll og en http-versjon.

Moderne nettlesere bruker versjon 1.1. Følgende er overskrifter i formatet "Navn: verdi".

HTTP-bufring

Poenget er at caching sikrer at HTML-sider og andre filer lagres i en cache (plass i driftsminnet, på datamaskinens harddisk). Dette er nødvendig for å fremskynde gjentatt tilgang til dem og spare trafikk.

Cachen har en klientnettleser, en mellomgateway og en proxy-server. Før du sender en melding til en URL, vil nettleseren sjekke om objektet er i hurtigbufferen. Hvis det ikke er noe objekt, sendes forespørselen til neste server, hvor det sjekkes for caching av http-hoder nginx server. Gatewayer og proxyer brukes av forskjellige brukere, så hurtigbufferen deles.

HTTP-bufring kan ikke bare øke hastigheten på nettstedet betydelig, men også gi en gammel versjon av siden. Dette brukes til å sende overskrifter til svaret. Informasjon som forespørres via HTTPS-protokollen kan imidlertid ikke bufres.

Beskrivelse av http-overskrifter

En av de viktigste cache-mekanismene er http expires-hodene. Disse overskriftene indikerer utløpsdatoen for informasjonen som er gitt i svaret. De angir klokkeslett og dato når cachen vil bli ansett som utdatert. For eksempel ser en slik overskrift slik ut: Utløper: Wen, 30. nov. 2016 13:45:00 GMT. Denne strukturen brukes nesten overalt, inkludert for caching av sider og bilder. Hvis brukeren velger gammel dato, vil informasjonen ikke bli bufret.

HTTP-proxy-hoder tilhører kategorien overskriftskobling. De er ikke bufret som standard. For at hurtigbufferen skal fungere riktig, må hver URL samsvare med én variant av innholdet. Hvis en side er tospråklig, bør hver versjon ha sin egen URL. Varier-overskriften forteller cachen navnene på forespørselshodene. For eksempel, hvis visningen av en forespørsel avhenger av nettleseren, må serveren også sende en header. Dermed lagrer cachen forskjellige varianter forespørsler og dokumenttyper. TTP aksept-overskriften er nødvendig for å kompilere lister over akseptable formater for ressursen som brukes; det er ganske enkelt å jobbe med det, siden det filtrerer bort unødvendige.

Det er totalt fire grupper med overskrifter som formidler offisiell informasjon. Dette er hovedhodene - de finnes i alle server- og klientmeldinger, forespørsel og svar og enhet. Sistnevnte beskriver innholdet i en melding fra klienten og serveren.

HTTP-autorisasjonshodet anses som valgfritt. Når en nettside ber klienten om autorisasjon, viser nettleseren et spesielt vindu med felt for å angi pålogging og passord. Etter at brukeren har skrevet inn informasjonen sin, sender nettleseren en http-forespørsel. Den inneholder overskriften "autorisasjon".

Hvordan kan jeg se overskriftene?

For å se http-overskriften må du installere nettleserplugins, for eksempel firefox:

• Firebug. Du kan se overskriftene i nettfanen, hvor du velger alle. Denne plugin-en har funksjoner som vil være nyttige for en webutvikler.
• Live http-overskrifter. En enkel plugin designet for å se http-overskrifter. Med dens hjelp kan du generere en forespørsel manuelt.
• Ghrome-brukere vil enkelt se overskriftene hvis de klikker på innstillingsknappen og velger utviklerverktøy (nettverk).

Når pluginene er installert, starter du dem i nettleseren din.

Spørremetoder

Metodene som brukes i HTTP ligner på instruksjoner som sendes som en melding til serveren. Dette er et spesielt ord for engelske språk.

• GET metoden. Den brukes til å be om informasjon fra en ressurs. Det er her alle handlinger begynner.
• POST. Den brukes til å sende data. For eksempel en melding i sosialt nettverk eller en kommentar, plasserer nettleseren den i brødteksten i POST-forespørselen og sender den til serveren.
• HODE. Metoden ligner den første, men utfører en enkel funksjon. Den ber bare om metadata, unntatt meldingen fra svaret. Denne metoden brukes hvis du ønsker å få informasjon om filer uten å laste ned. Den brukes hvis de ønsker å sjekke funksjonaliteten til lenker på serveren.
• SETTE. Laster data til en URL. Overfører store mengder data.
• ALTERNATIVER. Fungerer med serverkonfigurasjoner.
• URI. Identifiserer ressursen og inneholder URL.

HTTP-responsstruktur

Serveren svarer på klientforespørsler med lange meldinger. Svaret består av flere linjer som indikerer protokollversjonen og serverstatuskoden (200). Den forteller deg hva som har endret seg på serveren mens du behandler den innkommende forespørselen:

1. Statusen "to hundre" indikerer vellykket behandling av informasjon. Serveren sender deretter dokumentet til klienten. De resterende linjene i forespørselen indikerer annen informasjon om informasjonen som overføres.
2. Hvis filen ikke blir funnet eller ikke eksisterer, sender serveren en 404-kode til klienten, også kalt en feil.
3. Kode 206 indikerer en delvis nedlasting av filen, som kan gjenopptas etter en stund.
4. Kode 401 indikerer autorisasjon nektet. Dette betyr at den forespurte siden er beskyttet av et passord, som må angis for å bekrefte oppføringen.
5. Koden 403 indikerer forbudt tilgang.Forbud mot visning, nedlasting av filer eller videoer er en vanlig reaksjon på Internett.
6. Det finnes også andre versjoner av kodene: midlertidig flytting av den forespurte filen, Intern feil servere, siste trekk. I dette tilfellet vil brukeren bli omdirigert. Hvis kode 500 vises, betyr dette at det er problemer med serveren.

URL - hva er det?

URL-en er hjertet i nettkommunikasjon mellom klient og server. Forespørselen sendes vanligvis via en URL - Uniform Resource Locator. Struktur be om url veldig enkelt. Den består av flere elementer: http-protokoll (header), hoot (nettstedsadresse), port, ressursbane og spørring.

Protokollen er også tilgjengelig for sikker tilkobling https og informasjonsutveksling. En URL inneholder informasjon om plasseringen til et bestemt nettsted på Internett. Adressen inkluderer domenenavnet, banen til siden og tittelen.

Den største ulempen med å jobbe med nettadresser er den ubeleilige interaksjonen med det latinske alfabetet, samt tall og symboler. Optimalisering spiller en viktig rolle i SEO.

Aktive databrukere og utviklere oppfordres til å gjøre seg kjent med noen profesjonelle anbefalinger gitt av eksperter på dette feltet:

• Angi utløpsdatoer for filer og dokumenter, med hensyn til oppdateringer. Statistisk informasjon er angitt i store maks-aldersverdier.
• Et enkelt dokument skal bare være tilgjengelig via én URL.
• Hvis du oppdaterer en fil som skal lastes ned av en bruker, endrer du navnet og kobler til den. Dette sikrer at et nytt dokument lastes ned og ikke et utdatert.
• Sist endrede overskrifter må samsvare med den faktiske datoen innholdet sist ble endret. Du bør ikke lagre sider og dokumenter på nytt med mindre du endrer dem.
• Bruk bare POST-forespørsler der det er nødvendig. Hold SSL-arbeid på et minimum.
• Overskrifter bør sjekkes med REDbot-plugin-modulen før de sendes av serveren.

HTTP. Det er basert på interaksjon" klient server", det vil si at det antas at:

1. Forbruker- klient etter å ha startet en forbindelse med leverandør-serveren, sender den en forespørsel;
2. Forsørger- server, etter å ha mottatt forespørselen, utfører de nødvendige handlingene og returnerer et svar med resultatet tilbake til klienten.

   I dette tilfellet er det to mulige måter å organisere arbeidet til klientdatamaskinen på:

   • Tynn klient er en klientdatamaskin som overfører alle informasjonsbehandlingsoppgaver til serveren. Et eksempel på en tynnklient er en datamaskin med en nettleser som brukes til å jobbe med nettapplikasjoner.
   • Fet klient tvert imot, behandler informasjon uavhengig av serveren, og bruker sistnevnte hovedsakelig kun for datalagring.

Før vi går videre til spesifikke klient-server-webteknologier, la oss se på de grunnleggende prinsippene og strukturen til den grunnleggende HTTP-protokollen.

HTTP-protokoll

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - protokoll applikasjonsnivå for hypertekstoverføring.

Den sentrale enheten i HTTP er ressurs URL-en som ble pekt på i klientforespørselen. Vanligvis er disse ressursene filer som er lagret på serveren. En funksjon ved HTTP-protokollen er muligheten til å spesifisere i forespørselen og svaret metoden for å representere den samme ressursen i henhold til ulike parametere: format, koding, språk, etc. Det er takket være muligheten til å spesifisere metoden for å kode en melding at klienten og serveren kan utveksle binære data, men i utgangspunktet denne protokollen designet for å overføre symbolsk informasjon. Ved første øyekast kan dette virke som sløsing med ressurser. Faktisk tar data i symbolsk form mer minne, meldinger skaper ekstra belastning på kommunikasjonskanaler, men dette formatet har mange fordeler. Meldinger som sendes over nettverket er lesbare, og etter å ha analysert de mottatte dataene, Systemadministrator kan enkelt finne feilen og fikse den. Om nødvendig kan en person spille rollen som en av de interagerende applikasjonene ved manuelt å legge inn meldinger i det nødvendige formatet.

I motsetning til mange andre protokoller er HTTP en minneløs protokoll. Dette betyr at protokollen ikke lagrer informasjon om tidligere klientforespørsler og serversvar. Komponenter som bruker HTTP kan uavhengig opprettholde tilstandsinformasjon knyttet til siste forespørsler og svar. For eksempel klient Webapplikasjon, sender forespørsler, kan overvåke svarforsinkelser, og Internett server kan lagre IP-adresser og be om overskrifter for nylige klienter.

Alle programvare for arbeid med HTTP-protokollen er delt inn i tre hovedkategorier:

• Servere- tilbydere av informasjonslagring og -behandlingstjenester (forespørselsbehandling).
• Kunder- sluttforbrukere av servertjenester (sende forespørsler).
• Proxy-servereå støtte arbeidet med transporttjenestene.

Hovedkundene er nettlesere eks: Internett Utforsker, Opera, Mozilla Firefox, Netscape Navigator og andre. De mest populære webserverimplementeringene er: Internett Informasjon Tjenester (IIS), Apache, lighttpd, nginx. De mest kjente proxy-serverimplementeringene: Squid, UserGate, Multiproxy, Naviscope.

Det "klassiske" HTTP-øktskjemaet ser slik ut.

1. Etablere en TCP-tilkobling.
2. Kundeforespørsel.
3. Serverrespons.
4. Avslutter TCP-tilkoblingen.

Dermed sender klienten en forespørsel til serveren, mottar et svar fra den, hvoretter interaksjonen stopper. Vanligvis er klientforespørselen en forespørsel om å overføre et HTML-dokument eller en annen ressurs, og serversvaret inneholder koden for denne ressursen.

HTTP-forespørselen sendt av klienten til serveren inkluderer følgende komponenter.

• Statuslinje (noen ganger brukes begrepene statuslinje eller spørringslinje også for å referere til den).
• Overskriftsfelt.
• Tom linje.
• Forespørselsinstans.

Statuslinjen sammen med overskriftsfelt noen ganger også kalt forespørselsoverskrift.

Ris. 2.1.

Statuslinjen har følgende format:

request_method URL_pecypca protocol_version HTTP

La oss se på komponentene i statuslinjen, med spesiell oppmerksomhet til forespørselsmetodene.

Metode spesifisert i statuslinjen bestemmer hvordan ressursen hvis URL er angitt på samme linje påvirkes. Metoden kan ta verdiene GET, POST, HEAD, PUT, DELETE, etc. Til tross for overfloden av metoder, er bare to av dem virkelig viktige for en webprogrammerer: GET og POST.

• FÅ. I følge den formelle definisjonen er GET-metoden ment å skaffe en ressurs med en spesifisert URL. Ved mottak av en GET-forespørsel må serveren lese den spesifiserte ressursen og inkludere ressurskoden som en del av svaret til klienten. Ressursen hvis URL sendes som en del av forespørselen, trenger ikke å være en HTML-side, bildefil eller andre data. Ressurs-URLen kan peke til kjørbar programkode som, hvis visse betingelser er oppfylt, må kjøres på serveren. I dette tilfellet returneres ikke klienten programkoden, men dataene generert under utførelse. Selv om GET-metoden per definisjon er ment for å hente informasjon, kan den brukes til andre formål. GET-metoden er ganske egnet for å overføre små databiter til serveren.
• POST. I henhold til samme formelle definisjon er hovedformålet med POST-metoden å overføre data til serveren. I likhet med GET-metoden kan imidlertid POST-metoden brukes på mange forskjellige måter og brukes ofte til å hente informasjon fra en server. Som med GET-metoden, peker URL-en som er angitt i statuslinjen til en bestemt ressurs. POST metode kan også brukes til å starte en prosess.
• HEAD- og PUT-metodene er modifikasjoner av GET- og POST-metodene.

Protokollversjon HTTP er vanligvis spesifisert i følgende format:

HTTP/versjon.modifikasjon

Overskriftsfelt, etter statuslinjen, lar deg avgrense forespørselen, dvs. overføre tilleggsinformasjon til serveren. Overskriftsfeltet har følgende format:

Feltnavn: Verdi

Formålet med et felt bestemmes av navnet, som er atskilt fra verdien med et kolon.

Navnene på noen av de vanligste overskriftsfeltene i en klientforespørsel og deres formål er vist i tabell 2.1.

Tabell 2.1. HTTP-forespørselshodefelt.

Overskriftsfelt HTTP -be om	Betydning
Vert	Domenenavn eller IP-adresse til verten som klienten har tilgang til
Henviser	URL til dokumentet som refererer til ressursen som er oppført i statuslinjen
Fra	E-postadressen til brukeren som jobber med klienten
Aksepterer	MIME-typer av data behandlet av klienten. Dette feltet kan ha flere verdier, atskilt med komma. Ofte brukes feltet Accept header for å fortelle serveren hvilke typer grafiske filer klient støtter
Accept-Language	Et sett med identifikatorer med to tegn, atskilt med komma, som indikerer språkene som støttes av klienten
Accept-Charset	Liste over støttede tegnsett
Innholdstype	MIME-type data som finnes i forespørselsteksten (hvis forespørselen ikke består av en enkelt overskrift)
Innhold-lengde	Antall tegn i forespørselsteksten (hvis forespørselen ikke består av en enkelt overskrift)
Område	Tilstede dersom klienten ikke ber om hele dokumentet, men kun deler av det
Forbindelse	Brukes til å administrere TCP-tilkobling. Hvis feltet inneholder Lukk, betyr dette at serveren skal lukke forbindelsen etter å ha behandlet forespørselen. Keep-Alive-verdien foreslår å holde TCP-tilkoblingen åpen slik at den kan brukes til påfølgende forespørsler
Bruker agent	Kundeinformasjon

I mange tilfeller, når du arbeider på nettet, er det ingen forespørselsinstans. Når CGI-skript kjøres, kan dataene som sendes til dem i forespørselen, plasseres i forespørselens brødtekst.

I denne artikkelen skal vi se på hva overskrifter trengs til, uten å gå i detalj om hvem som er ansvarlig for hva. Rollene til de vanligste overskriftene vil bli beskrevet i påfølgende artikler.

Alle artiklene fra serien:

• Hva er Http-hoder? Generell teori.

HTTP står for HyperText Transfer Protocol. En protokoll er et sett med regler som forskjellige enheter utveksle data. Den ble opprettet på 1990-tallet. Nå brukes den nesten overalt på Internett. Alt du ser i nettleservinduet ble hentet gjennom denne protokollen. http-hoder er kanskje det viktigste i kommunikasjon mellom enheter. De formidler grunnleggende informasjon om forbindelsen som opprettes og overført informasjon gjennom denne forbindelsen.
La oss ta en titt på kommunikasjonsdiagrammet mellom de to enhetene. La disse enhetene være datamaskinen din og en server på Internett:

Som du kan se, sendte nettleseren en http-forespørsel. Det kan se noe slikt ut:

FÅ /other-19 HTTP/1.1 Vert: www.scriptsite.ru Brukeragent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Godta: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q= 0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Tilkobling: keep-alive

I dette tilfellet er den første linjen forespørselslinjen, alle andre linjer er http-overskrifter som inneholder tilleggsinformasjon om forespørselen, om klienten som ber om denne informasjonen, og om mange andre ting.
Som svar på vår forespørsel kan serveren sende følgende overskrifter:

Server: Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.8k mod_dp20/0.99.2 PHP/5.2.5 mod_python/3.3.1 Python/2.5.1 mod_ruby/1.2.6 Ruby/1.8.6 (2007-09-24) X-Powered-By: PHP/5.2.5 Set-Cookie: PHPSESSID=ft47gokfee6amv3eda3k1p93s3; sti=/ Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: ingen cache Keep-Alive: timeout=10, maks=1024 Tilkobling: Keep-Alive Overføringskoding: biter Innholdstype: tekst/html

Den første linjen er statuslinjen. De resterende linjene er overskrifter. Diagrammet viste at innholdet på siden også er lastet. Men dette innholdet vises vanligvis ikke i header viewer-plugins. Og innholdet på siden er bare spesielt tilfelle. I følge protokollen trenger ikke siden nødvendigvis å overføres. I stedet kan et bilde, en lydfil og en video overføres. Og alle av dem vil ha svært forskjellige overskrifter.

Hvordan ser jeg http-overskrifter?

For å se http-overskrifter anbefaler jeg følgende plugins for Firefox-nettleseren:

Hvis du bruker Chrome-nettleser, kan du se all informasjonen ved å klikke på innstillingsknappen - verktøy - utviklerverktøy. Nettverk-fanen.
For brukere opera nettleser Jeg kan ikke gi noen råd fordi jeg ikke er kjent med denne nettleseren. Når pluginene er installert og kjører, kan du prøve å oppdatere siden. Du vil umiddelbart se enorme lister over forespørsler og svar som nettleseren din kommuniserte med serveren gjennom.

Http-overskrifter og tilgang til dem i php

Hvis du er en PHP-utvikler, kan du få tilgang til forespørselshoder ved å bruke getallheaders()-funksjonen. For å forstå hvordan det fungerer, la oss kjøre følgende kode:

Og vi får en utskrift av header-arrayet.

Men oftere åpnes de gjennom den globale variabelen $_SERVER. Nesten hver http-header har et lignende elementnavn i denne variabelen, dannet i henhold til HTTP_header_name-prinsippet. Så for den samme 'User_Agent' er det en variabel $_SERVER['HTTP_USER_AGENT'];

For å få overskriftene som serveren skal sende til brukeren, brukes headers_list()-funksjonen. Som regel komponerer serveren de manglende påkrevde overskriftene på slutten av alle skript. Derfor vil denne matrisen inneholde overskriftene enten de som serveren opprettet før skriptet begynte å kjøre (og de vil ikke bli endret), eller de som vi satte manuelt. De kan stilles inn manuelt ved hjelp av funksjonsoverskriften ("header text");
La oss kjøre følgende kode:

Vi vil se en utskrift av overskriftene klare til å sendes på det tidspunktet funksjonen kalles:

Den første overskriften ble satt automatisk, og den bærer navnet på serveren som skriptet kjører på. Den andre ble installert manuelt av oss. Hvis nettleseren trengte "Fruit"-overskriften, ville den hente den fra serverens http-svar og bruke den. Men siden nettleseren vår ikke trenger det, ignorerer den ganske enkelt linjen den ikke forstår.

HTTP-forespørselsstruktur

Vår forespørsel ser slik ut:

Den første linjen i den, som nevnt tidligere, er spørringslinjen. Den består av tre deler:

• metode(metode) - indikerer hvilken type forespørsel. De vanligste metodene: GET, POST, HEAD. De vil bli skrevet om i neste avsnitt.
• sti(bane) - vanligvis er dette den delen av URL-en som kommer etter domenet. For eksempel hvis du går inn adressefeltet http://www.scriptsite.ru/about/, vil baneverdien være /about/.
• protokoll(protokoll) — protokollen som brukes. Består vanligvis av "HTTP" og protokollversjonen. Vanligvis i moderne nettlesere versjon 1.1 brukes

Deretter kommer overskriftene i form av strenger i formatet "Navn: verdi".
Forresten, informasjonskapseldata overføres også i denne forespørselen som en av overskriftene. De fleste av disse linjene er valgfrie. Spørringen kan reduseres til bare to linjer:

GET /article/show/4/ HTTP/1.1 Vert: scriptsite.ru

Forespørselsmetoder

FÅ

En get-forespørsel brukes vanligvis til å be om et dokument og sende noen parametere.
Dette er hovedmetoden som brukes for å få html-sider, bilder, css og JavaScript-filer, etc.
På grunn av det faktum at parametrene kan være hva som helst, og serveren ikke har noen begrensninger på hvordan de kan behandles, brukes ofte dataforespørselsmetoden for å overføre informasjon. For eksempel vil vi ha et skjema som dette

I dette tilfellet vil disse parameterne være synlige i adressefeltet til nettleseren.

POST

Post er metoden som brukes for å sende data til serveren. Selv om du kan sende data til serveren ved hjelp av GET-metoden gjennom nettleserens adresselinje, er det i de fleste tilfeller å foretrekke å bruke POST. Sende store volumer data via GET er upraktisk. I tillegg har GET noen begrensninger som ikke tillater for eksempel å publisere denne artikkelen på nettstedet mitt gjennom kun én nettleserlinje. POST-forespørsler brukes oftest til å sende inn nettskjemaer. La oss endre skjemaet fra forrige eksempel for å gi det en POST-metode

Overskriftene Content-Type og Content-Length legges til automatisk. De inneholder informasjon om typen og størrelsen på dataene.
Alle data overføres etter sending av overskrifter i samme form som på linjen FÅ forespørsel

POST-metoden brukes ofte i AJAX, cURL, etc.
Filopplastingsskjemaer fungerer kun via POST-metoden

HODE

Mange av dere er kanskje ikke klar over denne typen forespørsel.
Denne metoden fungerer på samme måte som post, bare serveren returnerer ikke noe annet innhold enn overskriftene.
Bruken av denne overskriften er berettiget i mange tilfeller. For eksempel når nettleseren en gang bufret en fil, og nå ønsker å finne ut om den har endret seg på serveren. Nettleseren kan be om informasjon om det uten å laste ned hele filen selv.
I tillegg brukes denne metoden ofte i tjenester som sjekker lenker for helse. Den lar deg finne ut hvilken URL-er Det er fortsatt filer, men for noen er de ikke der lenger, og igjen blir ikke filene lastet ned.

HTTP-responsstruktur

Serveren svarer på hver forespørsel med følgende svar:

Den første linjen er protokollversjonen.
Neste er serverstatuskoden. I gitt verdi koden er 200. Statuskoden viser nettleseren hva som skjedde på serveren mens forespørselen ble behandlet. Status nummer 200 betyr at forespørselen vår ble behandlet, og serveren vil sende det forespurte dokumentet umiddelbart etter at overskriftene er sendt.
De resterende linjene indikerer all slags informasjon om den overførte filen.

Til informasjonen om statuser kan du også legge til fakta om feil 404. Navnet kommer nettopp fra 404-koden som serveren sender når den ikke finner en fil på diskene sine.
Flere detaljer om serverstatuser er skrevet i neste artikkel.

Vær også oppmerksom på

HTTP (engelsk: Hyper Text Transfer Protocol) er en applikasjonslagsdataoverføringsprotokoll designet spesielt for utveksling av informasjon mellom et nettsted og en brukeragent (nettleser). Dette er en av de standardene som alle Verdensomspennende Web. Interaksjon søkemotorer med nettsteder foregår også innenfor HTTP-protokollen.

Det gir ingen mening å gjenfortelle innholdet i RFC her i sin helhet og i detalj - nedenfor er lenker for detaljert informasjon. Bare det minimum som er nødvendig for å forstå i protokollen er skissert her.

Om vilkår

Mange begreper kan forstås i forskjellige betydninger. Det er nødvendig å umiddelbart bli enige i hvilken forstand dette eller det begrepet brukes i denne artikkelen.

Webserver (server)- ikke en datamaskin som ligger i et datasenter, men et program som kjøres på denne datamaskinen som mottar forespørsler og sender de forespurte dokumentene.
Brukeragent (klient, brukeragent)- et program som sender forespørsler til en webserver og mottar dokumenter fra den. Dette kan være nettleseren din, eller det kan være en robot som gjennomsøker en søkemotor.
Dokument- enhver individuell informasjon som har sin egen adresse i domenet. Som standard er det antatt HTML-side, men filer med tegninger, CSS, Java-skript osv. regnes også som dokumenter.

Prosedyre for informasjonsutveksling

HTTP har bare to typer meldinger: klientforespørsel og serversvar. Klienten sender en forespørsel til serveren, og angir domenenavnet og adressen innenfor domenet der nødvendig dokument. Serveren mottar meldingen, søker etter dokumentet (eller kjører skriptet som genererer dette dokumentet) og sender en svarmelding etter vellykket fullføring.
Strukturen til disse meldingene er den samme:

Startlinje

Overskrifter

Meldingstekst

Startlinjen og overskriftslinjene blir ofte referert til som "forespørsel" (eller svar) overskriften.
Eksempel på en startspørringslinje:

FÅ /index.php HTTP/1.1

Forespørselsmetoden (GET), adressen til dokumentet innenfor domenet og protokollversjonen som brukes, overføres.
Eksempel på svarstartlinje:

HTTP/1.1 200 OK

Protokollversjonen, numerisk statuskode (200) og statusdekoding (OK) ble overført.

Overskrifter

Forespørselshodene inneholder Tilleggsinformasjon, noe som kan påvirke videre meldinger. Navnet på domenet som dokumentet er forespurt fra er påkrevd. Den forventede medietypen til dokumentet, muligheten til å motta i et komprimert format, det forventede språket for tekstdokumenter og navnet på brukeragenten som sendte forespørselen kan også overføres. Overskriften kan også formidle betingelsene for forespørselen. For eksempel, If-Modified-Since: [tidsstempel] - ber om et dokument forutsatt at innholdet har endret seg siden tidspunktet angitt i overskriften.

Svarhodet inneholder også tilleggsinformasjon - navnet på serveren, nåværende tid, medietype og koding av det overførte dokumentet, eventuelt andre data (språk for tekstdokumenter, endringsdato, størrelse i byte osv.). Alt dette er ledsagende informasjon til dokumentet, som vil bli overført etter overskriftene (i brødteksten i meldingen) hvis forespørselen er vellykket.

Hvis det er umulig å overføre et dokument, tilsvarer statuskoden i servermeldingen arten av feilen, og i stedet for hoveddelen av dokumentet sendes en spesiell HTML-side med teksten til feilmeldingen. Vær oppmerksom på at feilstatusen ikke hindrer nettleseren fra å vise denne siden.

Forespørselsmetoder

Protokollen som endret av RFC 2616 beskriver åtte metoder for å få tilgang til serveren. Men i dag er ikke alle implementert for de fleste webservere, og bare to er anerkjent som obligatoriske for implementering. De viktigste metodene som interesserer oss og støttes av nesten alle webservere er GET, HEAD og POST.

GET metoden

Dette er mest normal metode be om å få en nettside eller annet dokument. Som svar på denne forespørselen må serveren finne (eller generere) et dokument og, ved vellykket gjennomføring, sende det til klienten.
Forespørselsformat:

FÅ HTTP[protokollversjon]

HEAD metode

Denne metoden ligner på GET, men med én forskjell: som svar på en HEAD-forespørsel, utfører serveren et oppslag (eller dokumentgenerering), men sender bare svarhodene, uten å sende meldingsteksten. På denne måten kan du sjekke eksistensen eller tilgjengeligheten av et dokument på en gitt adresse, og få all informasjon om dokumentet som er overført i overskriftene, uten å motta selve dokumentet.
Forespørselsformat:

HEAD HTTP[protokollversjon]

Det er ingen meldingstekst i forespørselen.

POST metode

Denne metoden er ment å overføre data til serveren - for eksempel overføres data som legges inn i et skjema vanligvis ved hjelp av POST-metoden.
Forespørselsformat:

POST HTTP[protokollversjon]

[URI]-feltet inneholder adressen til skjemabehandlerskriptet som mottar og behandler dataene. Brødteksten i meldingen inneholder dataene som er lagt inn i skjemafeltene i skjemaet [field_name=entered_value].

Statuskoder

Statuskoder (status) viser resultatet av forespørselen som behandles av serveren. Koden er representert med tre sifre desimal, hvorav den mest betydningsfulle biten indikerer klassen til responsen. Dermed er opptil hundre forskjellige statuskoder reservert for hver klasse med svar. Totalt fem klasser er definert:

1xx: Informasjon - informativ

Koder fra 100 til 199 inkludert i denne klassen informerer klienten om at forespørselen er mottatt. Meldinger med slike statuser inneholder kun startlinje og (om nødvendig) overskrifter, men inneholder ikke meldingsteksten. Klienten skal ikke sende noe som svar på dette.

2xx: Suksess - vellykket

Meldinger fra denne klassen indikerer at forespørselen ble mottatt, tolket og behandlet. Av disse statuskodene er vi bare interessert i 200 "OK" - et tegn på normal fullføring, hvoretter det forespurte dokumentet sendes til klienten i selve meldingen.

HTTP(HyperText Transfer Protocol – “hypertekstoverføringsprotokoll”) er en protokoll på applikasjonsnivå for dataoverføring (opprinnelig i form av hypertekstdokumenter). Grunnlaget for HTTP er klient-server-teknologien, det vil si at den antar eksistensen av forbrukere (klienter) som starter tilkoblingen og sender en forespørsel, og leverandører (servere) som venter på at tilkoblingen mottar forespørselen og gjør nødvendige handlinger og returner en melding med resultatet.

HTTP brukes også som en "transport" for andre applikasjonslagsprotokoller, som SOAP, XML-RPC, WebDAV.

Hovedobjektet for manipulasjon i HTTP er ressursen pekt på av URI (Uniform Resource Identifier) ​​i klientforespørselen. Vanligvis er disse ressursene filer som er lagret på serveren, men de kan være logiske objekter eller noe abstrakt. En funksjon ved HTTP-protokollen er muligheten til å spesifisere i forespørselen og svaret metoden for å representere den samme ressursen i henhold til ulike parametere: format, koding, språk, etc. Det er takket være muligheten til å spesifisere metoden for å kode en melding at klienten og serveren kan utveksle binære data, selv om denne protokollen er tekst.

HTTP er en applikasjonslagsprotokoll, lik den er FTP og SMTP - Simple Mail Transfer Protocol. Meldinger utveksles i henhold til den vanlige forespørsel-svar-ordningen. HTTP bruker globale URIer for å identifisere ressurser. I motsetning til mange andre protokoller er HTTP statsløs. Dette betyr at det ikke er noen vedvarende mellomtilstand mellom forespørsel-svar-par. Komponenter som bruker HTTP kan uavhengig opprettholde tilstandsinformasjon knyttet til nylige forespørsler og svar. Nettleseren som sender forespørslene kan spore svarforsinkelser. Serveren kan lagre IP-adressene og be om overskrifter til de siste klientene. Protokollen i seg selv kjenner imidlertid ikke til tidligere forespørsler og svar, den gir ikke intern statlig støtte, og det stilles ingen slike krav til den.

Utvidbarhet

Protokollens muligheter utvides enkelt ved å introdusere egne overskrifter, samtidig som kompatibilitet med andre klienter og servere opprettholdes. De vil ignorere overskrifter som er ukjente for dem, men samtidig kan de få den nødvendige funksjonaliteten for å løse spesifikke problemer.

HTTP/1.1 - Gjeldende versjon protokoll. Nytt i denne versjonen var " permanent tilkobling": En TCP-tilkobling kan forbli åpen etter å ha sendt et svar på en forespørsel, slik at flere forespørsler kan sendes i en enkelt tilkobling. Klienten er nå pålagt å sende informasjon om navnet på verten den har tilgang til, noe som gjorde det mulig å organisere virtuell hosting enklere.

HTTP lagrer ikke informasjon om transaksjoner, så du må starte på nytt i neste transaksjon. Fordelen er at HTTP-serveren kan betjene mange flere klienter i løpet av en gitt tidsperiode fordi overheaden med sporingsøkter fra en tilkobling til en annen elimineres. Det er også en ulempe: å lagre informasjon om transaksjoner er mer komplisert CGI-programmer må bruke skjulte inndatafelt eller med eksterne midler, for eksempel Cookie.

Metoder HTTP-forespørsel

HTTP-metoden- en sekvens av alle tegn, bortsett fra kontroller og skilletegn, som indikerer hovedoperasjonen på ressursen. Vanligvis er metoden et kort engelsk ord skrevet med store bokstaver. Vær oppmerksom på at metodenavnet skiller mellom store og små bokstaver.

Hver server må støtte minst GET- og HEAD-metodene. Hvis serveren ikke gjenkjenner metoden spesifisert av klienten, skal den returnere status 501 (Ikke implementert). Hvis serveren kjenner metoden, men den ikke er relevant for en spesifikk ressurs, returneres en melding med kode 405 (Method Not Allowed). I begge tilfeller SKAL serveren inkludere en Tillat-overskrift i svarmeldingen med en liste over støttede metoder.

I tillegg til metodene GET og HEAD, brukes ofte POST-metoden.

• HTTP-forespørsel, svar, enhetsoverskrifter (parametere)

  Alle overskrifter i HTTP-protokollen er delt inn i fire hovedgrupper (det anbefales å sende overskrifter til mottakeren i rekkefølgen nedenfor):

  Generelle overskrifter(Hovedhoder) - må inkluderes i enhver klient- og servermelding.

  Forespørselshoder(Request headers) - brukes kun i klientforespørsler.

  Svarhoder(Responshoder) - kun for svar fra serveren.

  Enhetsoverskrifter(Entitetshoder) - følger med hver meldingsenhet. I egen klasse Enhetsoverskrifter er uthevet for å unngå forvirring med forespørselshoder eller svarhoder for overføring av flere innhold (MIME).

  Alle overskrifter som er nødvendige for at HTTP skal fungere er beskrevet i hoved-RFCene. Om nødvendig kan du lage dine egne overskrifter. Tradisjonelt er navnene på slike tilleggshoder prefikset med "X-" for å unngå navnekonflikter med muligens eksisterende.

  Linjene etter hovedforespørselslinjen (GET /index.html HTTP/1.1) har følgende format: Parameter: verdi. Dette er hvordan forespørselsparametrene settes. Dette er valgfritt; alle linjer etter hovedspørrelinjen kan mangle; i dette tilfellet aksepterer serveren deres verdi som standard eller basert på resultatene fra forrige forespørsel (når du arbeider i Connection: Keep-Alive-modus).

  Parameter Forbindelse(tilkobling) - kan ta verdiene Keep-Alive og lukke. I HTTP 1.0 følges serverens overføring av de forespurte dataene av en frakobling fra klienten, og transaksjonen anses som fullført med mindre Connection: Keep Alive-overskriften sendes. I HTTP 1.1 stenger ikke serveren tilkoblingen som standard, og klienten kan sende andre forespørsler. Fordi mange dokumenter har andre dokumenter innebygd – bilder, rammer, appleter, osv. – sparer dette tid og kostnader for klienten, som ellers ville måtte koble flere ganger til samme server for å få bare én side. Således, i HTTP 1.1, kan en transaksjon sløyfe til klienten eller serveren eksplisitt lukker forbindelsen.

  Parameter Bruker agent- verdien er "koden" til nettleseren.

  Parameter Aksepterer- en liste over innholdstyper som støttes av nettleseren i rekkefølge etter preferanse for denne nettleseren.

  Parameter Vert- navnet på domenet som ressursen er forespurt fra. Nyttig hvis serveren har flere virtuelle servere under én IP-adresse. I dette tilfellet navnet virtuelt domene bestemt av dette feltet.

  Parameter Sist endret(endret i sist) (W3C Last-Modified) - dato og klokkeslett siste endring dokument. Ved å bruke den kan klienten, i likhet med tilfellet med ETag, kontakte serveren med en "If-Modified-Since"-forespørsel - i dette tilfellet må serveren sammenligne siste endringsdato for kopien som er lagret på klienten med den faktiske siste endringsdato. Hvis de stemmer, betyr dette at kopien i klientens cache ikke er utdatert, og last ned på nytt ikke nødvendig (svarkode "304 Ikke endret"). Last-Modified er også nødvendig for korrekt behandling av nettstedet av roboter, som bruker informasjon om datoen for endring av sider for å sortere søkeresultater etter dato, samt for å bestemme frekvensen av oppdatering av nettstedet ditt.

  For SSI-dokumenter vil Apache utstede "Last-Modified" hvis "XBitHack full"-direktivet er spesifisert (for eksempel i .htaccess-filen)

  Parameter ETag(objekt-tag) - introdusert i HTTP 1.1 (W3C ETag). ETag brukes til å tildele hver side en unik identifikator, hvis verdi endres når siden (dokumentet) endres. ETag er en hash ("fingeravtrykk") av bytene til dokumentet; hvis til og med én byte i dokumentet endres, vil ETag endres. ETag brukes ved hurtigbufring av et dokument. Denne overskriften lagres på klienten, og i tilfelle gjentatt tilgang til dokumentet lar den nettleseren kontakte serveren med en 'If-None-Match'-forespørsel, og serveren må bestemme ved verdien av ETag-taggen om dokumentet (siden) er endret, og hvis ikke, svar med koden '304 Ikke endret'.

  Parameter Utløper(expiration)(W3C Expires) - den forteller nettleseren hvilken tidsperiode den kan anta at kopien av siden i cachen er fersk, og ikke kontakte serveren med forespørsler i det hele tatt. Dette er praktisk for filer som du med sikkerhet vet ikke vil endre seg den neste timen/dagen/måneden: bakgrunnsbilde sider, for eksempel.

  Andre HTTP-hoder:

  HTTP_X_FORWARDED_FOR

  HTTP_X_FORWARDED

  HTTP_FORWARDED_FOR

  • HTTP_X_COMING_FROM

    HTTP_COMING_FROM

  • HTTP_X_CLUSTER_CLIENT_IP

  • HTTP_XROXY_CONNECTION

    HTTP_PROXY_CONNECTION

    HTTP_USERAGENT_VIA - proxy

  Eksempel på analyse av HTTP-forespørsel

  En HTTP-forespørsel består av tre deler: en forespørsel (svar)-linje, en overskriftsdel, etterfulgt av en valgfri tekst. Overskrifter er ren tekst, med hver overskrift atskilt fra den neste med et linjeskifttegn (\r\n), mens brødteksten kan være enten tekst eller binære data. Brødteksten er atskilt fra overskriftene med to nye linjer.

  Forespørselsoverskriften består av forespørselens hovedlinje (første) og påfølgende linjer som tydeliggjør forespørselen i hovedlinje. Påfølgende linjer kan også mangle.

  Kunden starter en transaksjon som følger:

  Klienten oppretter en forbindelse med serveren ved å bruke det tildelte portnummeret, offisielt nummer Standardporten er 80. Klienten sender deretter en dokumentforespørsel, som spesifiserer metoden, dokumentadressen og HTTP-versjonsnummeret. For eksempel, i hovedforespørselslinjen GET /index.html HTTP/1.1

  GET-metoden brukes til å be om index.html-dokumentet ved hjelp av HTTP-versjon 1.1.

  Klienten sender topptekstinformasjon (valgfritt; vertshodet er nødvendig) for å fortelle serveren sin konfigurasjonsinformasjon og informasjon om dokumentformatene den kan akseptere. All overskriftsinformasjon er listet opp linje for linje, med hver linje som inneholder et navn og en verdi. Følgende overskrift sendt av en klient inneholder for eksempel navnet og versjonsnummeret, samt informasjon om noen av klientens foretrukne dokumenttyper: Host: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Godta: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

  Overskriften avsluttes med en tom linje.

  Etter å ha sendt en forespørsel og overskrifter, kan klienten sende tilleggsdata, for eksempel for CGI-skript.

  Serveren svarer på klientforespørselen som følger:

  Den første delen av serversvaret er statuslinjen, som inneholder tre felt: HTTP-versjon, statuskode og beskrivelse. Versjonsfeltet inneholder HTTP-versjonsnummeret som denne serveren bruker for å sende svaret. Statuskoden er et tresifret tall som indikerer resultatet av serveren som behandler klientforespørselen. Beskrivelsen som følger statuskoden er ganske enkelt lesbar tekst som forklarer statuskoden. For eksempel HTTP/1.1 statuslinje 304 Ikke endret

  indikerer at serveren bruker HTTP versjon 1.1 for å svare. Statuskode 304 betyr at klienten ba om dokumentet ved hjelp av GET-metoden, brukte If-Modified-Since eller If-None-Match-overskriften, og dokumentet har ikke endret seg siden det angitte øyeblikket.

  Etter statuslinjen sender serveren overskriftsinformasjon til klienten som inneholder informasjon om selve serveren og det forespurte dokumentet. Nedenfor er en eksempeloverskrift: Dato: tor, 15. desember 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Utløper: tor, 19. nov. 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vari: Accept-Encoding Content-Encoding: gzip Keep - Alive: timeout=5, max=100 Tilkobling: Keep-Alive Content-Type: text/html; charset=utf-8

  Overskriften avsluttes med en tom linje.

  Hvis klientens forespørsel er vellykket, sendes de forespurte dataene. Dette kan være en kopi av en fil eller resultatet av et CGI-program. Hvis klientens forespørsel ikke kan tilfredsstilles, overføres tilleggsdata i form av en brukervennlig forklaring på årsakene til at serveren ikke var i stand til å oppfylle forespørselen.

  HTTP-statuskode

  HTTP-statuskode er en del av den første linjen i serversvaret. Det er et tresifret heltall. Det første sifferet angir tilstandens klasse. Svarkoden blir vanligvis etterfulgt av en forklarende setning på engelsk atskilt med et mellomrom, som forklarer personen årsaken til denne spesielle responsen.

  Klienten kjenner kanskje ikke alle statuskoder, men den må svare i henhold til kodens klasse. Det er for øyeblikket fem klasser med statuskoder:

  1xx: Informasjon. Informasjonsstatuskoder som forteller klienten at serveren er i ferd med å behandle en forespørsel. Kundens reaksjon på disse kodene er ikke nødvendig;

  2xx: Suksess.

  1. 200 OK(Fint). Introdusert i HTTP/1.0. Vellykket ressursforespørsel. Hvis klienten ba om noen data, finnes de i overskriften og/eller brødteksten i meldingen.

  3xx: Omdirigering. Klasse 3xx-koder forteller klienten at en annen forespørsel (vanligvis til en annen URI) må gjøres for at operasjonen skal lykkes. Av denne klassen er fem koder 301, 302, 303, 305 og 307 direkte knyttet til omdirigeringer (viderekobling). Adressen som klienten skal sende forespørselen til, angis av serveren i posisjonsoverskriften. Mange klienter, når de omdirigerer med kodene 301 og 302, bruker feilaktig GET-metoden på den andre ressursen, til tross for at forespørselen til den første var med en annen metode. For å unngå misforståelser ble HTTP/1.1-kodene 303 og 307 introdusert i stedet for 302. Du må bare endre forespørselsmetoden hvis serveren svarte med 303. I andre tilfeller gjør du neste forespørsel med den opprinnelige metoden.

  1. 302 funnet(Funnet). Introdusert i HTTP/1.0. Det forespurte dokumentet er midlertidig tilgjengelig på en annen URI angitt i overskriften i feltet Sted.

  4xx: Klientfeil. 4xx-kodeklassen er ment å indikere feil på klientsiden. Når du bruker alle metoder unntatt HEAD, må serveren returnere en hypertekstforklaring til brukeren i brødteksten i meldingen.

  1. 404 Ikke funnet(Ikke funnet). Introdusert i HTTP/1.0. Serveren forsto forespørselen, men fant ikke en tilsvarende ressurs på den angitte URIen.

  5xx: serverfeil(Serverfeil)

  HTTP 1.1-relaterte lenker

  HTTP/2

  HTTP/2 (opprinnelig HTTP/2.0) - andre hovedversjon nettverksprotokoll HTTP. Protokollen er basert på SPDY (HTTP-kompatibel protokoll utviklet av Google).

  HTTP/2-protokollen er binær. Sammenlignet med forrige standard er metodene for å bryte data i fragmenter og transportere dem mellom server og klient endret.

  I HTTP/2 har serveren rett til å sende innhold som ennå ikke er etterspurt av klienten. Dette vil tillate serveren å umiddelbart sende ytterligere filer som nettleseren trenger for å vise sidene, uten at nettleseren trenger å analysere hovedsiden og be om de nødvendige tilleggene.