HTTP

HTTP
Հապավում	HTTP
Տեսակ	ցանցային արձանագրություն
Ընտանիք	TCP/IP
Մասն է	TCP/IP և համաշխարհային սարդոստայն
Ստեղծման ամսաթիվ	1989
Հրատարակման ամսաթիվ	1990[1][2]
Պորտ	80, 80 և 80
Գործակալներ	Internet Explorer, Chrome, Opera, Mozilla Firefox և այլն
Սերվերներ	Apache, IIS, nginx, Google Web Server և այլն
Hypertext Transfer Protocol Վիքիպահեստում

HTTP (անգլ.՝ HyperText Transfer Protocol), հիպերտեքստ, կառուցվածքային տեքստ, որը կապում է հիպերհղումները համակարգչային գիտության մեջ ծրագրային հաղորդակարգին (այսուհետ՝ պրոտոկոլ), որը պարունակում է տեքստ։ HTTP պրոտոկոլը թույլ է տալիս փոխանակել կամ տեղափոխել հիպերտեքստ։

HTTP ստանդարտները մշակվել են Internet Engineering Task Force (IETF) և World Wide Web Consortium (W3C) ընկերությունների կողմից, ինչը հանգեցրել (անգլ.՝ Requests for Comments (RFCs)), և RFC 2616 (1999 թվականի հունիս), ինչը սահմանել է HTTP/1.1 տարբերակը, որը մինչ այժմ լայնորեն օգտագործվում է։ 2014 թվականի հունիսին RFC 2616 տարբերակից անցում կատարվեց, և HTTP/1.1 վերամշակվեց RFC 7230, 7231, 7232, 7233, 7234 և 7235 տարբերակներով^[3]։ HTTP/2 տարբերակը դեռևս գտնվում է փորձնական փուլում։

HTTP հարց-պատասխան ծրագրային արձանագրությունը ծառայում է օգտատեր-սպասարկիչ համակարգչային մոդելի համար։ Վեբ դիտարկիչը, որպես օրինակ, կարող է լինել «սպասառու» ծրագիր, որը աշխատում է համակարգչի վրա, և այն համակարգիչը, որի վրա տեղակայված է վեբ կայքը կարող է կոչվել «սերվեր» կամ «սպասարկիչ համակարգիչ»։ Այսուհետ՝ սերվեր։

Օգտագործողը սերվերին ուղարկում է HTTP «հրամաններ»։ Սերվերը կամ «սպասարկիչ համակարգիչը», որը ապահովում է տվյալների հասանելիությունը, ինչպիսիք են HTML ֆայլերը կամ այլ պարունակություն, կամ կատարում է որևէ յուրահատուկ գործողություն՝ ըստ օգտագործողի հարցման, ապա վերադարձնում «արդյունքը» օգտագործողին։ Պատասխանը իրենից ներկայացնում է հարցման վերաբերյալ աշխատանքի կատարման արդյունքի վերաբերյալ, ինչպես նաև հաղորդագրության մեջ կարող է պարունակել հարցված կոնտենտը։

Վեբ դիտարկիչը «օգտագործողի գործակալի» օրինակ է։ «Օգտագործողի գործակալ» ծրագրերի այլ տեսակներն են ինդեքսավորող ծրագրերը, որոնք օգտագործվում են որոնողական համակարգերի, բջջային ծրագրերի, ձայնային դիտարկիչների, ինչպես նաև այլ ծրագրերի կողմից վեբ կոնտենտ օգտագործելու, մշակելու և ցուցադրու համար։

HTTP պրոտոկոլը մշակված է այնպես, որ հնարավորություն ստեղծվի ցանցային էլեմենտների համար բարելավված ��աղորդակցությունը օգտագործողի և սերվերի միջև։ Մեծ հոսք ունեցող վեբ կայքերը հաճախ օգտագործում են վեբ պահեստներ, որոնք հնարավորություն են տալիս հասցնել կոնտենտը սերվերից օգտագործողին՝ ավելի արագ պատասխան տալու միջոցով։ Վեբ սերվերները պահեստավորում են նախկինում այցելած վեբ ռեսուրսները և հնարավորության դեպքում վերօգտագործում դրանք՝ քչացնելով ցանցային հոսքը։ HTTP պրոքսի սերվերները ներքին ցանցի սահմաններում կարող է հեշտացնել օգտագործողի հաղորադկցությունը առանց գլոբալ հասցեների՝ արտաքին սերվերների հաղորդագրությունների վրա հիմնվելով։

HTTP ծրագրային շերտի պրոտոկոլ է, որը մշակված է ինտերնետային պրոտոկոլի լրակազմի (անգլ.՝ Internet Protocol Suite) կառուցվածքից առանձին։ Այս պրոտոկոլի սահմանում է վստահելի և ֆոնային փոխանակման շերտ^[4]։ Այնուամենայնիվ, HTTP պրոտոկոլը կարող է օգտագործլ անվստահելի պրոտոկոլներն, ինչպես օրինակ User Datagram Protocol (UDP) պրոտոկոլը Simple Service Discovery Protocol (SSDP) ծառայության դեպքում։

HTTP ռեսուրսները ցանցում ճանաչվում և տեղակայվում են «ռեսուրսների միատեսակ կաղապարների ճանաչում» (անգլ.՝ Uniform Resource Identifier) (URIs) կամ, ավելի մասնավոր դեպքերում՝ «կաղապարների տեղորոշիչների» (անգլ.՝ Uniform Resource Locators) (URLs) միջոցով՝ օգտագործելով http կամ https URI սխեմաներ. URI և հիպերհղումներ, հիպերտեքստի նշարկման լեզվով (HTML) ստեղծված փաստաթղթեր, ներկցված հիպերտեքստային փաստաթղթեր։

HTTP/1.1 տարբերակը սկզբնական HTTP (HTTP/1.0) տարբերակի վերամշակումն է։ HTTP/1.0 տարբերակը յուրաքանչյուր ռեսուրսի հարցման համար կատարվում է կապի առկայության վրա հիմնված առանձին հաղորդակցում սերվերի հետ։ HTTP/1.1 տարբերակը կարող է մի քանի անգամ վերօգտագործել միացումը նկարներ բեռնելու, օգտագործողի կողմից սկրիպտավորման, ոճի թերթերը (անգլ.՝ Cascading Style Sheets (CSS)) բեռնելու համար, երբ էջը արդեն տեղ է հասցված։

Հիպերտեքստ հասկացությունը ստեղծվել է Թեդ Նելսոնի կողմից 1995 թվականին։ Թիմ Բերներս-Լին և իր թիմը հիշատակվում են որպես օրիգինալ HTTP ստանդարտի և դրան հարակից տեխնոլոգիաների մշակող, որոնք օգտագործվում են վեբ սերվերի և տեսքստերի վրա հիմնված վեբ դիտարկիչների համար։

Բերներս Լին առաջին անգամ «WorldWideWeb» նախագիծը նախագծել է 1989 թվականին, որը մեզ հայտնի է որպես համաշխարհային սարդոստայն World Wide Web։ Պրոտոկոլի առաջին տարբերակը ունեցել է փոխացման միայն մեկ մեթոդ՝ GET, որը հարցում էր կատարում սերվերին՝ էջը դիտելու պահանջով^[5]։

HTTP առաջին փաստաթղթավործված տարբերակը եղել է HTTP V0.9 (1991). Դեյվ Ռագեթը ղեկավարում էր HTTP աշխատանքային խումբը (HTTP WG) 1995 թվականին և ցանկանում էր ընդլայնել պրոտոկոլը ավելի շատ գործողությունների, պայմանների, ավելի հարուստ մետա-ինֆորմացիայի, անվտանգության կցված պրոտոկոլի հնարավորություններ ունենալու համար, ինչը դարձավ ավելի օգտակար՝ ավելացնելով մեթոդներ և գլխագրեր։^[6][7] RFC 1945 տարբերակը պաշտոնապես ներկայացվել է և ճանաչվել որպես HTTP V1.0 1996 թվականին։

HTTP աշխատանքային խումբը պլանավորել էր թողարկել նոր ստանդարտները 1995 թվականին^[8] և ստանդարտի HTTP/1.1 նախատիպը հիմնված էր զարգացող ու մշակվող RFC 2068 (անվանումը՝ HTTP-NG) տարբերակի վրա, որը մեծ արագությամբ հարմարեցվել է վեբ ֆիտարկիչներ մշակող մեծ կազմակերպությունների կողմից 1996 թվականի սկզբներին։ 1996 թվականի մարտին HTTP/1.1 HTTP/1.1ստանդարտի նախատիպը ստացել էր աջակցություն Arena,^[9] Netscape 2.0,^[9] Netscape Navigator Gold 2.01,^[9] Mosaic 2.7, Lynx 2.5 և Internet Explorer 2.0 վեբ դիտարկիչներում։

Հարմարեցումները վերջնական օգտագործողին նոր դիտարկիչների միջոցով հասել են շատ արագ։ 1996 թվականի մարտին հոսթինգ ընկերություններից մեկը հայտարարել է, որ օգտագործվող դիտարկիչների 40 տոկոսը HTTP 1.1 ստանդարտը հաճոյակատար կերպով են օգտագործում։ Այդ նույն վեբ հոսթինգի ընկերությունը 1996 թվականի հունիս ամսին զեկուցել է, որ իրենց սերվերներին միացող դիտարկիչների 65 տոկոսը օգտագործել է HTTP/1.1 ստանդարտը։^[10] HTTP/1.1 ստանդարտը, ինչպես հաստատված է RFC 2068 ստանդարտով, պաշտոնապես թողարկվել է 1997 թվականին։ HTTP/1.1 տարբերակի բարելավումները և թարմացումները թողարկվել են RFC 2616 ստանդարտի մեջ՝ 1999 հունիսին։

2007 թվականին ստեղծվել է HTTPbis Working Group խումբը, որպեսզի պարզեցվեն HTTP/1.1 տեխնիկական տվյալները։ 2014 թվականի հունիսին աշխատանքային խումբը թողարկեց 6 մասից բաղկացած թարմացումը, որը անգործունակ և հնացած դարձրեց RFC 2616 ստանդարտը։

• RFC 7230 - HTTP/1.1։ Հաղորդագրություններ շարահյուսություն և ուղղորդում
• RFC 7231 - HTTP/1.1։ Իմաստաբանություն և բովանդակություն
• RFC 7232 - HTTP/1.1։ Պայմանական հարցումներ
• RFC 7233 - HTTP/1.1։ Միջակայքային հարցումներ
• RFC 7234 - HTTP/1.1։ Պահեստավորում քեշում
• RFC 7235 - HTTP/1.1։ Նույնականացում

HTTP աշխատաշրջանը (անգլ.՝ HTTP Session) ցանցի հարցումների և պատասխանների փոխանակման հաջորդականությունն է։ HTTP օգտագործողը հողորդում է հարցումը Transmission Control Protocol (TCP) պրոտոկոլով կապ հաստատելով տվյալ սերվերի TCP և UDP միանցքների (անգլ.՝ port) հետ (80, 8080)։ HTTP սերվերը, որը գործում է այդ միացնքի վրա, սպասում է օգտագործողի հարցման հաղորդագրությանը։ Հարցման պահանջը ստանալիս սերվերը ետ է ուղարկում իրավիճակի վերաբերյալ հաղորդագրություն, ինչպես օրինակ "HTTP/1.1 200 OK", և իր կողմից գրված հաղորդագրությունը. Այս հաղորդագրության պարունակությունը որպես կանոն հարցված ռեսուրսն է, ինչպես նաև սխալների վերաբերյալ հաղորդագրությունները, կամ այլ վերաբերող ինֆորմացիա։

HTTP պրոտոկոլը սահմանում է մեթոդներ (հաճախ անվանվում են «բայեր»), որոնք հնարավորություն են ընձեռում իրագործել ցանկալի գործողությունը։ Թե ինչ է այդ ռեսուրսը իրենից ներկայացնում, ինչպես նախկինում գոյություն ունեցող տվյալները կամ այն տվյալները, որոնք գեներացվում են դինամիկ կերպով, կախված են սերվերի գործողություններից։ Հաճախ ռեսուրսը համապատասխանում է որևէ ֆայլի կամ սերվերի վրա առկա գործարկվող ֆայլերի արտածմանը։

HTTP/1.0 հատկանիշները^[11] սահմանում էին GET, POST և HEAD մեթոդներ և HTTP/1.1 տարբերակի հատկանիշները^[12] ավելացվել էին 5 նոր մեթոդներով. OPTIONS, PUT, DELETE, TRACE և CONNECT. Մասնագիտացված լինելով այս փաստաթղթերի մեջ, դրանց իմաստաբանությունը ճանաչված է և կարող է նախօրոք մտածված լինել։ Ցանկացած սպասառու և սերվեր կարող են կարգավորվել ցանկացած մեթոդների կոմբինացիաներ աջակցելու համար։ Եթե մեթոդը անծանոթ է, այն կհամարվի վտանգավոր մեթոդ. Մեթոդների քանակը սահմանափակված չէ և դրանք կարող են սահմանվել ապագա մեթոդների համար, ինչը չի խանգարի ներկայիս գործող ինֆրահամակարգին։ Օրինակի համար WebDAV-ը սահմանել է 7 նոր մեթոդների և RFC 5789 տարբերակ, որը իրենից ներկայացնում է PATCH մեթոդ։

GET

մեթոդը հարցում է կատարում սահմանված ռեսուրսի ցուցադրման համար։ GET մեթոդով հարցումները կարող են միայն ստանալ տվյալներ և չեն կարող ունենալ այլ ազդեցություն (Սա հատուկ է նաև որոշ այլ HTTP մեթոդների)։

HEAD

մեթոդը հարում է կատարում GET հարցման նման, բայց առանց պատասխան հաղորդագրության։ Սա օգտակար է մետա ինֆորմացիա ստանալու համար, որոնք գրվում են պատասխան վերնագրերում՝ առանց ամբողջ կոնտենտը փոխանակելու կարիք ունենալու։

POST

մեթոդը պահանջում է սերվերից, որ այն ընդունի միավորների ցուցակը, որը կցված է հարցմանը՝ որպես URI -ի կողմից ճանաչված վեբ ռեսուրսների նոր ստարադաս։ Տվյալները կարող են POST հրամանով օգտագործվել գոյություն ունեցող ռեսուրսների ծանոթագրության, հասցեատերերի ցուցակների, մեկնաբանությունների, տվյալների աղյուսակում կամ տվյալների բազայում վեբ կաղապարների միջոցով տվյալներ մուտքագրելու համար։^[13]

PUT

Մեթոդը հարցում է կատարում որպեսզի միավորների խումբը պահպանվի հատկացված URI-ում։ Եթե այդ URI-ը հղում է կատարում արդեն գոյություն ունցեող ռեսուրսի, այն փոփոխվում է, եթե այն գոյություն չունի, ապա սերվերը ստեղծում է այդ URI-ը։^[14]

DELETE

Հեռացնում է տվյալ ռեսուրսը։

TRACE

Կրկնօրինակում է ստացված հարցումը, որպեսզի օգտագործողը նույնպես տեսնի, թե ինչ փոփոխություններ կամ հավելումներ են կատարվել սերվերի կողմից։

OPTIONS

Վերադարձնում է HTTP մեթոդը, որը սերվերը աջակցում է նշված URL. Սա կարող է օգտագործվել սերվերի աշխատունակությունը ստուգելու համար '*' հարցում ուղարկելով, այլ ռեսուրս հարցում կատարելու փոխարեն։

CONNECT

Մեթոդը փոխակերպում է հարցման կապը թափանցիկ TCP/IP թունելի, հիմնականում որպեսզի ապահովվի SSL-կոդավորում ունեցող հաղորդակցում՝ (HTTPS)՝ չկոդավորված HTTP պրոքսիի միջոցով։^[15][16]

HTTP սերվերներից պահանջվնում է նվազագույնը GET և HEAD մեթոդների ապահովում։^[17] և երբ հնարավոր է՝ նաև OPTIONS մեթոդի աջակցություն։

Մեթոդներից որոշները (օրինակ՝ HEAD, GET, OPTIONS և TRACE) համաձայն կոնվենցիաների՝ սահմանվախ են որպես «անվտանգ» մեթոդներ, ինչը նշանակում է դրանք նպատակաուղղված են միայն ինֆորմացիա ստանալու համար և չպետք է փոխեն սերվերի վիճակը։ Այլ կերպ ասած՝ նրանք չպետք է ունենան կողմնակի ազդեցություններ, բացի արձանագրումից, պահեստավորումից, բաներային գովազդից կամ օգտակար վեբ հաշվիչներից։ Կատարելով կամայական GET հարցումներ առանց ծրագրի կոնտքստի իրավիճակի հաշվի առնելու, այնուամենայնիվ, պետք է համարվի անվտանգ։ Չնայած, որ սա ստանդարտներով հաստատված չէ և ուղղակիորեն համարվում է, որ անհնար է ապահովել անվտանգությունը։

Որպես համեմատություն, մեթոդները, ինչպիսիք են POST, PUT, DELETE և PATCH, կարող են ծառայել այնպիսի արարքների համար, որոնք կառաջացնեն կողմնակի ազդեցություններ, ինչպիսիք են ֆինանսական գործարքները կամ էլեկտրոնային փոստի նամակների փոխանակում։ Այսպիսի մեթոդները այնուամենայնիվ, միշտ չէ, որ օգտագործվում են վեբ ռոբոտների կողմից ստուգվելու միջոցով։ Չնայած այն ամենի, ինչ ներկայացվել է GET հարցման վերաբերյալ, տեսականորն նրանց աշխատանքը սերվերի կողմից տեխնիկապես ոչ մի կերպ չի սահմանափակվում։ Այնուամենայնիվ անփույթ կամ մտածված ծրագրավորումը կարող է հանգեցնել սերվեր վրա անդառնալի փոփոխություններ։ Սա չի խրախուսվում, քանի որ կարող է պատճառ դառնալ վեբ պահեստավորման, որոնողական համակարգերի և այլ ավտոմատացված գործակալների աշխատանքի խնդիրների, ինչը կարող է չնախատեսված փոփոխությունների պատճառ դառնալ։

PUT և DELETE մեթոդները համարվում են իդեմպոտենտ, ինչը նշաննակում է, որ բազմակի նույնական հարցումները կարող են ունենալ նույն ազդեցությունը որպես միասնական հարցում (իդեմպոտենցիան վերաբե��ում է համակարգի այն վիճակին, երբ այն ավարտել է հարցումը, այսպիսով գործողությունները, որ սերվերը կատարում է (օրինակ՝ ջնջել կամ գրառել) կամ պատասխան կոդը, որը նա վերադարձնում է, կարող են լինել տարբեր հերթական հարցումներ, համակարգի վիճակը միշտ կլինի նույնը։

GET, HEAD, OPTIONS և TRACE մեթոդները, ներկայացվելով որպես անվտանգ մեթոդներ, նույնպես պետք է լինեն անկախ, ինչպես HTTP պրոտոկոլը՝ իրավիճակ չունեցող պրոտոկոլ։ Որպես համեմատություն, POST մեթոդը պարտադիր կերպով չէ, որ պետք է լինի իդեմպոտենտ, և չնայած նրան, որ նույնական POST հարցումները բազմակի անգամ կատարելու դեպքում հնարավոր է առաջացնել հետագա կողմնակի ազդեցություններ (ինչպիսիք են ֆինանսական գործարքները)։ Որոշ դեպքերում սա կարող է ցանկալի լինեն, բայց այլ դեպքերում դա կարող է արդյունք լինեն որևէ միջադեպի, ինչպես օրինակ երբ օգտատերը չի գիտակցում որ իր արարքները կարող են հանգեցնել այլ հարցումների ուղարկման, կամ և երբ նա չի ստանում պատճաշ հետադարձ հաղորդագրություն իր առաջին հարցման վերաբերյալ։

Մինչդեռ վեբ դիտարկիչը կարող է ցուցադրել զգուցածման պատուհան, այդպիսով օգտագործողին զգուշացնելով, որ էջի թարմացումը կարող է հայցել տվյալների կրկնակի հարցման, հիմնականում վեբ ծրագրերի խնդիրն է ապահովել ճշտությունը այն դեպքերում, երբ POST հարցումը չպետք է ուղարկվի մեկից ավելի անգամ։ Հարկավոր է ուշադրություն դարձնել, որ անկախ նրանից, թե մեդոթը իդեեմպոտենտ է թե ոչ, չի ազդում սերվերի կա պրոտոկոլի վրա։ Մեծ հավանականություն կա գրելու վեբ ծրագիրը, որտեղ, որպես օրինակ, տվյալների բազայում ավելացման կամ այլ ոչ իդեմպոտենտ գործողությունները պատճառ կհանդիսանան կամ այլ հարցումների։ Անտեսելով այլ խորհուրդը, ամեն դեպքում, կարող է հանգեցնել անցանկալի հետևանքների, եթե օգտագործողի «գործակալը» հաշվի առնի, թե երբ է անվտանգ և երբ վտանգավոր կրկնելու նույն հարցումը։

Իրականացվող մեթոդները, ինչպիսք են TRACE, TRACK և DEBUG, որոշ պրոֆեսիոնալների կողմից համարվում են վտանգավոր, որովհետև հարձակում գործողները կարող են օգտագործել դրանք ինֆորմացիա հավաքելու, հարձակման ժամանակ անվտանգությունը թուլացնելու համար։ Անվտանգության ծրագրային գործիքները, ինչպես օրինակ Tenable Nessus և Microsoft UrlScan Security Tool, որոնք ցուցադրում են անվտանգության խնդիրները այս մեթոդները օգտագործելուց։^[18] TRACK և DEBUG մեթոդները HTTP 1.1 գրանցված բայեր չեն։^[19]

HTTP/1.0 տարբերակից սկսած HTTP պատասխանների առաջին շարքը կոչվել է «կարգավիճակի տող» և պարունակում է թվային «կարգավիճակի կոդ» (ինչպես օրինակ "404") և տեքստային «պատճառը ներկայացնուղ դաշտը» (ինչպես օրինակ "Not Found")։ Այն, թե ինչպես է օգտագործողի «գործակալը» (անգլ.՝ User agent) գործածում պատասխանը, ուղղակիորեն կախված է կոդից։ Կարգավիճակիների անհատական կոդերը կարող են օգտագործվել այն ժամանակից սկսված, երբ օգտագործողի «գործակալը» հանդիպում է կոդի, որը չի կարողանում ճանաչել, այն կարող է օգտագործել սխալի կոդի առաջին թիվը՝ հասկանալու, թե պատասխանը որ գլխավոր բաժնին է վերաբերում։^[20]

Նաև «պատճառների» ստանդարտ նախադասությունները համարվում են միան խորհուրդներ և կարող են վեբ ծրագրավորողի կեղմից փոխարինվել «տեղական համարժեքներով»։ Եթե կարգավիճակի կոդը հարուցում է խնդիր, օգտագործողի «գործակալը» կարող է ցուցադրել սխալի վերաբերյալ «պատճառի» տողը՝ ցուցադրելու խնդրի առաջացման վերաբերյալ ինֆորմացիա։ Այս ստանդարտը օգտագործողի «գործակալին» հնարավորություն է տալիս թարգմանել «պատճառի» նախադասությունը, սակայն սա կարող է լինել սխալ, քանզի ստանդարտները սահմանում են, որ կարգավիճակի կոդերը սարքերի կողմից կարդացվող, իկս «պատճառի» նախասդասությունները մարդկանց կողմից կարդավող են։ HTTP կարգավիճակի կոդերը որպես կանոն բաժանվախ են 5 խմբերի, որպեսզի ավելի լավ բացատրվի հարցումների և պատասխանների բացատրությունները օգտագործողի և սերվերի միջև հետևյալ կերպ՝ Ինֆորմացիոն 1XX, Հաջող ավարտ 2XX, Վերահասցեավորում 3XX, Օգտագործողի «գործակալի» կողմից սխալ 4XX Սերվերի կողմից սխալ 5XX.

HTTP/0.9 և 1.0 տարբերակներում յուրաքանչյուր հարցում/պատասխան զույգից հետո կապը անջատվում է։ HTTP/1.1 տարբերակում ներկայացվեց «կապի սպասողական վիճակի պահպանում» հնարավորությունը, որտեղ կապը կարող է օգտագործվել ավելի քան մեկ անգամ։ Այսպիսով «կայուն կապ» հասկացությունը ապահովում է հարցման զգալի բարելավում, քանի որ օգտագործողի «գործակալը» կարիք չունի կրկին հարցում կատարել նոր հարցում, որբ առաջինը արդեն ուղարկվել է։ Մեկ այլ դրական կողմ է հիմնականում կապի արագության բարձրացումը, որը տեղի է ունենում շնորհիվ։

Պրոտոկոլի 1.1 տարբերակի մեջ կատարվել են նաև թողունակության մի շարք բարելավումներ համեմատելով HTTP/1.0 տարբերակի հետ։ Օրինակի համար HTTP/1.1 տարբերակը ներկայացրեց մասատված փոխանցման կոդավորումը, որը հնարավորություն տվեց կայուն կապի դեպքում տվյալները հոսքով ուղարկել բուֆերում պահելու փոխարեն։ HTTP խողովակաշարը հետագայում նվազեցրեց սպասման ժամանակը, ինչ թույլ տվեց օգտագործողների «գործակալներին» ուղարկելու բազմակի հարցումներ՝ չսպասելով յուրաքանչյուր հարցման պատասխանին։ Պրոտոկոլի մեկ այլ բարելավում է բայթերով մատուցումը, որտեղ սերվերը հաղորդում է միայն օգտագործողի կողմից արտահայտված կերպով հարցված ռեսուրսների չափաբաժինը։

HTTP վիճակ չունեցող պրոտոկոլ է։ Վիճակ չունեցող պրոտոկոլը HTTP սերվերից բազմակի միացման ժամանակ չի պահանջում ինֆորմացիա կամ յուրաքանչյուր օգտագործողիկարգավիճակի մասին տվյալներ։ Բայց որոշ վեբ ծրագրեր կիրառում են սերվերային կողմի սեսիաներ, ինչպես օրինակ HTTP cookie կամ թաքնված պայմանականներ, որոնք դուրս են վեբ կաղապարներից։

Ամենատարածված ձևը HTTP կապում անվտանգություն ապահովելու համար «անվտանգ» HTTP` HTTP Secure (https) պրոտոկոլն է։

Գոյություն ունեն նաև երկու այլ կոդավորված HTTP կապի հաստատման միջոցներ՝ Secure Hypertext Transfer Protocol և HTTP/1.1 Upgrade header։ Այս երկու տարբերակների համար այնուամենայնիվ, դիտարկիչները աջակցումը գրեթե չկա։ Այսպիսով HTTP Secure պրոտոկոլը գերակշռող մեթոդն է մնում կոդավորված HTTP կապ հաստատելու համար^[21]

Հարցման հաղորդագրությունը բաղկացած է հետևյալ կետերից.

• Հարցման տող, օրինակի համար՝ GET /images/logo.png HTTP/1.1, որը հարցում է կատարում սերվերից /images/logo.png ռեսուրսի համար։
• Հարցումների վերնագրերի տողեր, ինչպես օրինակ Accept-Language։ en
• Դատարկ տող
• Հաղորդագրության ոչ պարտադիր պարունակություն

Հարցման տողը և այլ վերնագրային տողերից յուրաքանչյուրը պետք է ավարտվի <CR><LF> կոդով։ Դատարկ տողը պետք է բաղկացած լինի միայն <CR><LF> նիշերից և ոչ մի այլ ազատ տարածք^[22] HTTP/1.1 պրոտոկոլում բոլոր վերնագրային տողերը բացի Host տողից կամայական են։

Մինչև HTTP/1.0 RFC 1945 տարբերակից առաջ սերվերները ընդունում էին հարցում, որը պարունակում էր միայն ուղու անվանումը, որպեսզի համապատասխանությունը պահպանվեր նախկինում ստեղծված HTTP գործակալների հետ։^[23]

Պատասխան հաղորդագրությունը բաղկացած է հետևյալ կետերից.

• Կարգավիճակի տող, որը պարունակում է կարգավիճակների կոդեր և պատճճառի վերաբերյալ հաղորդագրություն։ (Օրինակ՝ HTTP/1.1 200 OK, ինչը ցույց թ տալիս, որը օգտագործողի հարցումը հաջողությամբ կատարվել է)
• HTTP պատասխանների վերնագրի տողեր, ինչպիսիք են text/html
• Դատարկ տող
• Հաղորդագրության ոչ պարտադիր պարունակություն

Հաղորդագրության տողը և այլ վերնագրերի տողեր պետք է վերջանան <CR><LF>։ Դատարկ տողը պետք է բաղկացած լինի միայն <CR><LF> և չլինի ոչ մի այլ բաց տարածություն^[22]

Ներքում ցուցադրվում է պարզ երկխոսության տարբերակ HTTP սպասառուի և HTTP սերվերի միջև, որոնք գործում են www.example.com, 80 միացքի (պորտ) վրա։

GET /index.html HTTP/1.1
Host: www.example.com

Սպասառուի հարցումը (այս դեպքում բաղկացած է հարցման տողից և միայն մեկ վերնագրային տողից) շարունակվում է դատարկ տողով, որպեսզի հարցումը ավարտվի կրկնակի նոր տողով, որոնցից յուրաքանչյուրը փոխանցման վերադարձի տեսքով։ "Host" տողը տարբերակվում է տարբեր DNS անվանումների միջև՝ կիսելով մեկ IP հասցե, ինչը թույլ է տալիս ստեղծել անվանումների վրա հիմնված վիտուալ հոսթինգ։ HTTP/1.0 տարբերակում սա կամընտրական էր, իսկ HTTP/1.1 տարբերակում՝ պարտադիր։

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b"
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

ETag (entity tag) վերնագրային տողը օգտագործվում է պարզելու, արդյոք պահեստավորված տարբերակը համապատասխանում է սերվերի վրա առկա ներկա տարբերակին թե ոչ։ Content-Type սահմանում է HTTP հաղորդագրության միջոցով փոխանցվող տվյալների ինտերնետային մեդիա տեսակը, մինչդեռ Content-Length տողը ցուցադրում է դրա երկարությունը բայթերով։ HTTP/1.1 վեբ սերվերը ներկայացնում է հնարավորություն պատասխանելու փաստաթղթերին տարբեր բայթային միջակայքերում տեղադրելով Accept-Ranges: bytes տողը։ Սա օգտակար է, եթե սպասառուին հարկավոր է ունենալ միայն մեկ հաստատոււն մաս^[24] այդ պատասխանից, որը ուղարկվել է սերվերի կողմից և կոչվում է բայթային մատուցում. Երբ Connection: close հրամանը ուղարկվում է, նշանակում է, որ վեբ սերվերը փակելու է TCP կապը այս հարցման պատասխանը տալուց անմիջապես հետո։

Վերնագրային տողերի մեծ մասը կամայական են։ Երբ Content-Length տողը բացակայում է, երկարություն սահմանվում է այլ միջոցներով։ is missing the length is determined in other ways. Մասնատված փոխանցման կոդավորումը օգտագործում է մասնատված 0-ական բաժինները կոնտենտի ավարտը նշելու համար։

«Կոնտենտի կոդավորումը», ինչպիսին օրինակ gzip ն է, կարող է օգտագործվել ուղարկվող տվյլաները սեղմելու համար։

Գոպֆեր պրոտոկոլը տվյալների փոխանցման պրոտոկոլ էր, որը տեղաշարժվել է HTTP պրոտոկոլի կողմի 1990-ական թվականների սկզբներին։ Նոր SPDY պրոտոկոլը նույնպես նման է HTTP պրոտոկոլին, միայն փոփոխված է հարցման-պատասխանի հաղորդակցումը սպասառույի և սերվերի միջև։

• HTTP 0.9 – As Implemented in 1991

Վիքիպահեստ նախագծում կարող եք այս նյութի վերաբերյալ հավելյալ պատկերազարդում գտնել HTTP կատեգորիայում։

• «Change History for HTTP». W3.org. Վերցված է 2010-08-01-ին. A detailed technical history of HTTP.
• «Design Issues for HTTP». W3.org. Վերցված է 2010-08-01-ին. Design Issues by Berners-Lee when he was designing the protocol.
• «Classic HTTP Documents». W3.org. 1998-05-14. Վերցված է 2010-08-01-ին. list of other classic documents recounting the early protocol history

Այս հոդվածն ընտրվել է Հայերեն Վիքիպեդիայի օրվա հոդված:

Վիքիպահեստն ունի նյութեր, որոնք վերաբերում են «HTTP» հոդվածին։

Բառարաններ և հանրագիտարաններ Բրիտանիկա · Բրոքհաուս · Մեծ նորվեգական · Treccani Չափորոշչային վերահսկողություն BNF: 12556450f · GND: 4479982-2 · LCCN: sh97000529 · Microsoft: 149672775