HTTP

01Հաղորդագրության ֆորմատը

HTTP-ն request–response պրոտոկոլ է, ինչպես մատուցողը, որն ընդունում է պատվերը և բերում ուտեստը։ Հարցումն ունի սկզբնական տող (մեթոդ, path, տարբերակ), header-ներ (key: value զույգեր) և ոչ պարտադիր body։ Պատասխանն ունի status տող (տարբերակ, կոդ, պատճառ), header-ներ և ոչ պարտադիր body։ HTTP-ն stateless է․ յուրաքանչյուր հարցում ինքնուրույն է, իսկ վիճակը, օրինակ՝ login-ը, փոխանցվում է cookie-ներով կամ token-ներով։ HTTP/2-ում և HTTP/3-ում նույն հաղորդագրություններն ուղարկվում են որպես բինար frame-եր, բայց իմաստը նույնն է, ուստի ներքևի տեքստային ձևը դեռ լավագույն միջոցն է դրանց մասին մտածելու համար։

1POST /api/orders HTTP/1.1
2Host: api.example.com
3Content-Type: application/json
4Authorization: Bearer <token>
5Content-Length: 39
6 
7{"productId": 42, "quantity": 2}
8 
9HTTP/1.1 201 Created
10Location: /api/orders/1001
11Content-Type: application/json
12 
13{"id": 1001, "status": "pending"}

02Մեթոդները և նրանց խոստումները

GET-ը կարդում է ռեսուրսը և ոչինչ չպետք է փոխի։ HEAD-ը GET է առանց body-ի, օգտակար է ստուգումների համար։ POST-ը ինչ-որ բան ստեղծում է կամ գործողություն է գործարկում։ PUT-ը ռեսուրսն ամբողջությամբ փոխարինում է, PATCH-ը փոխում է դրա մի մասը, DELETE-ը ջնջում է այն։ OPTIONS-ը հարցնում է, թե ինչ է թույլատրված, և օգտագործվում է CORS preflight-երում։ Երկու հատկություն կարևոր է։ Safe մեթոդները (GET, HEAD, OPTIONS) վիճակ չեն փոխում, ուստի crawler-ները և prefetcher-ները կարող են ազատ կանչել դրանք։ Idempotent մեթոդները (GET, HEAD, PUT, DELETE, OPTIONS) կրկնվելիս նույն արդյունքն են տալիս, ուստի client-ները կարող են timeout-ից հետո կրկնել դրանք։ POST-ն ու PATCH-ը լռելյայն idempotent չեն․ POST-ի կրկնությունը կարող է երկու պատվեր ստեղծել, եթե սերվերը չի օգտագործում idempotency key։

• Երբեք տվյալներ մի փոխեք GET-ով․ link preview-ն կամ prefetch-ը կարող է այն գործարկել։
• Ավտոմատ կրկնեք միայն idempotent հարցումները։
• Չաջակցվող մեթոդների համար օգտագործեք 405 Method Not Allowed՝ Allow header-ով։

03Status code-երի ընտանիքները

Առաջին թվանշանը պատմում է ամբողջ պատմությունը։ 1xx՝ տեղեկատվական (103 Early Hints-ը թույլ է տալիս սերվերին preload ակնարկներ ուղարկել իրական պատասխանից առաջ)։ 2xx՝ հաջողություն՝ 200 OK, 201 Created, 204 No Content։ 3xx՝ վերաուղղորդում՝ 301 և 308 մշտական, 302 և 307 ժամանակավոր (307-ն ու 308-ը պահպանում են մեթոդը և body-ն), 304 Not Modified՝ քեշավորման համար։ 4xx՝ client-ի սխալներ՝ 400 Bad Request, 401 Unauthorized (նույնականացված չէ), 403 Forbidden (նույնականացված է, բայց թույլատրված չէ), 404 Not Found, 405, 409 Conflict, 410 Gone, 413 Payload Too Large, 415 Unsupported Media Type, 422 Unprocessable Content (վալիդացիա), 429 Too Many Requests։ 5xx՝ սերվերի սխալներ՝ 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout։ Ճիշտ կոդերը թույլ են տալիս client-ներին, քեշերին, մոնիտորինգին և որոնողական համակարգերին ճիշտ վարվել՝ առանց body-ն կարդալու։

04Header-ներ և cookie-ներ

Header-ները կրում են մետատվյալներ։ Հարցման՝ Host, Accept, Accept-Language, Authorization, Content-Type, User-Agent, Cookie։ Պատասխանի՝ Content-Type, Content-Length, Location, Set-Cookie, Cache-Control և անվտանգության header-ներ, ինչպիսիք են Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff և Referrer-Policy։ Cookie-ները փոքր արժեքներ են, որոնք սերվերը խնդրում է բրաուզերին պահել և հետ ուղարկել այդ կայքին ուղղված յուրաքանչյուր հարցման հետ։ Flag-երն են որոշում, թե որքան անվտանգ են դրանք։ Secure՝ ուղարկվում է միայն HTTPS-ով։ HttpOnly՝ JavaScript-ը չի կարող այն կարդալ, ինչը սահմանափակում է XSS-ի վնասը։ SameSite=Lax-ը (բրաուզերի լռելյայնը) արգելափակում է ուղարկումը cross-site հարցումների մեծ մասում, Strict-ը արգելափակում է բոլորը, None-ը թույլ է տալիս cross-site, բայց պահանջում է Secure։ Path-ը, Domain-ը և Max-Age-ը կառավարում են տիրույթն ու կյանքի տևողությունը։ __Host- նախածանցը պարտադրում է Secure, Path=/ և Domain-ի բացակայություն։

1HTTP/1.1 200 OK
2Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200
3Strict-Transport-Security: max-age=31536000; includeSubDomains
4X-Content-Type-Options: nosniff
5Referrer-Policy: strict-origin-when-cross-origin
6Content-Security-Policy: default-src 'self'; img-src 'self' data:

05Քեշավորում՝ Cache-Control, ETag, 304

Քեշավորումը խնայում է աշխատանքը։ Cache-Control-ը բրաուզերներին և CDN-ներին ասում է՝ ինչ անել․ max-age=31536000, immutable՝ տարբերակավորված ռեսուրսների համար, ինչպիսին է app.3f9a1c.js-ը, no-cache՝ HTML-ի համար, որը կարելի է պահել, բայց ամեն անգամ պետք է revalidate անել, no-store՝ զգայուն տվյալների համար, որոնք երբեք չպետք է պահվեն, private՝ պատասխանների համար, որոնք նախատեսված են միայն մեկ օգտատիրոջ բրաուզերի համար, s-maxage՝ ընդհանուր քեշերի, օրինակ՝ CDN-ների համար, stale-while-revalidate՝ մի փոքր հին պատճենը մատուցելու համար, մինչ ֆոնում թարմացվում է։ Validator-ները revalidation-ը դարձնում են էժան․ սերվերն ուղարկում է ETag (մատնահետք) կամ Last-Modified, բրաուզերը հետո ուղարկում է If-None-Match կամ If-Modified-Since, և եթե ոչինչ չի փոխվել, սերվերը պատասխանում է 304 Not Modified՝ առանց body-ի։ Vary-ն քեշերին ասում է, թե որ հարցման header-ներն են փոխում պատասխանը, օրինակ՝ Accept-Encoding-ը։

1GET /app.css HTTP/1.1
2Host: example.com
3If-None-Match: "a1b2c3"
4 
5HTTP/1.1 304 Not Modified
6ETag: "a1b2c3"
7Cache-Control: no-cache

06CORS առանց շփոթության

Բրաուզերները կիրառում են same-origin policy․ https://app.example.com-ի էջը չի կարող կարդալ https://api.example.com-ի պատասխանները, եթե API-ն դա թույլ չի տալիս։ CORS-ը (Cross-Origin Resource Sharing) այն եղանակն է, որով սերվերը պատասխանի header-ներով տալիս է այդ թույլտվությունը։ Պարզ հարցումներին պետք է միայն Access-Control-Allow-Origin։ JSON body-ով, Authorization-ի նման custom header-ներով կամ PUT-ի և DELETE-ի նման մեթոդներով հարցումները գործարկում են preflight․ բրաուզերը նախ ուղարկում է OPTIONS՝ հարցնելով, թե արդյոք իրական հարցումը թույլատրված է։ Եթե cookie-ներ են ներգրավված, սերվերը պետք է վերադարձնի ճշգրիտ origin-ը (ոչ թե *) և Access-Control-Allow-Credentials: true։ CORS-ը կիրառվում է միայն բրաուզերների կողմից․ այն ձեր API-ն չի պաշտպանում curl-ից կամ այլ սերվերներից, ուստի նույնականացումը դեռ պետք է։

1OPTIONS /api/orders HTTP/1.1
2Origin: https://app.example.com
3Access-Control-Request-Method: POST
4Access-Control-Request-Headers: content-type, authorization
5 
6HTTP/1.1 204 No Content
7Access-Control-Allow-Origin: https://app.example.com
8Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
9Access-Control-Allow-Headers: content-type, authorization
10Access-Control-Allow-Credentials: true
11Access-Control-Max-Age: 600
12Vary: Origin

07HTTP-ի ուսումնասիրությունը գործնականում

Բրաուզերի Network tab-ը ցույց է տալիս յուրաքանչյուր հարցում՝ header-ներով, ժամանակներով, cookie-ներով և պատասխանով։ Աջ սեղմեք հարցման վրա և ընտրեք Copy as cURL՝ այն տերմինալում վերարտադրելու համար։ curl -v-ն տպում է ամբողջ փոխանակումը, -I-ն բերում է միայն header-ները։ API-ների համար օգնում են Postman-ը, Insomnia-ն կամ HTTPie-ն, բայց runbook-ում պարզ curl-ն ամենաշարժականն է։ Debug անելիս կողք կողքի համեմատեք աշխատող և չաշխատող հարցումները․ սովորաբար մեկ header-ը, cookie-ն կամ status code-ն է բացատրում տարբերությունը։ Չմոռանաք հեռացնել token-ներն ու cookie-ները՝ նախքան պատճենված հարցումը որևէ մեկի հետ կիսվելը։

1curl -sI https://example.com/                      # headers only
2curl -v https://api.example.com/health             # full exchange
3curl -s -X POST https://api.example.com/orders \
4  -H "Content-Type: application/json" \
5  -H "Authorization: Bearer $TOKEN" \
6  -d '{"productId":42,"quantity":2}' -w "\n%{http_code}\n"

08Message framing և request smuggling

HTTP/1.1-ում ստացողը պետք է իմանա, թե որտեղ է ավարտվում body-ն։ Content-Length-ը տալիս է չափը բայթերով, Transfer-Encoding: chunked-ը body-ն ուղարկում է կտորներով՝ յուրաքանչյուրն իր երկարությամբ, և ավարտվում է զրո չափի chunk-ով։ Եթե հարցումը պարունակում է երկուսն էլ, կամ դրանցից մեկի սխալ ձևաչափված տարբերակը, առջևի proxy-ն և back-end սերվերը կարող են չհամաձայնել, թե որտեղ է ավարտվում հարցումը։ Այդ դեպքում հարձակվողը կարող է առաջին հարցման body-ի մեջ թաքցնել երկրորդ հարցումը, որը back end-ը կընդունի որպես հաջորդ օգտատիրոջ հարցման սկիզբ։ Սա HTTP request smuggling է, և այն կարող է շրջանցել անվտանգության կանոնները կամ «թունավորել» քեշը։ Պաշտպանություն. proxy-ները և սերվերները թարմ պահեք, մերժեք երկու header-ով կամ անվավեր framing-ով հարցումները, հնարավորության դեպքում նախընտրեք HTTP/2 ամբողջ ճանապարհին և խուսափեք ձեռքով գրված proxy-ներից։ HTTP/2-ը և HTTP/3-ը ունեն իրենց սեփական framing-ը, բայց proxy-ում HTTP/1.1-ի downgrade-ը ռիսկը վերադարձնում է։

09Conditional request-ներ՝ ապահով միաժամանակյա թարմացումների համար

Երկու ադմին բացում են նույն ապրանքը, երկուսն էլ խմբագրում են, և երկրորդի պահպանումը լուռ վերագրում է առաջինին. սա lost update խնդիրն է։ HTTP-ն այն լուծում է validator-ներով։ GET պատասխանը ներառում է ETag (տարբերակի fingerprint)։ Client-ը փոփոխությունն ուղարկում է If-Match-ով՝ սահմանված այդ ETag-ին։ Եթե ռեսուրսն այդ ընթացքում փոխվել է, սերվերը մերժում է 412 Precondition Failed-ով, և client-ը վերաբեռնում ու միավորում է փոփոխությունները։ PUT-ի վրա If-None-Match: *-ը նշանակում է՝ ստեղծել միայն եթե գոյություն չունի, ինչը կանխում է պատահական վերագրումները։ Սերվերները կարող են գրառումների վրա պարտադրել precondition-ներ 428 Precondition Required-ով։ Ներսում սա հարմար համընկնում է version սյունակին կամ updated_at ստուգմանը մեկ UPDATE ... WHERE version = ? հրամանում, այնպես որ ստուգումը և գրառումը ատոմար են։

1GET /api/products/42 HTTP/1.1
2 
3HTTP/1.1 200 OK
4ETag: "v7"
5 
6PATCH /api/products/42 HTTP/1.1
7If-Match: "v7"
8Content-Type: application/json
9 
10{"price": 4900}
11 
12HTTP/1.1 412 Precondition Failed      # someone saved v8 first

10Content negotiation, Vary և range request-ներ

Մեկ URL-ը կարող է ունենալ մի քանի ներկայացում։ Client-ը նախընտրությունները նշում է Accept, Accept-Language և Accept-Encoding header-ներով, իսկ սերվերն ընտրում է մեկը՝ իդեալում պատասխանելով 406, երբ ոչինչ չի համապատասխանում։ Ցանկացած header, որը փոխում է պատասխանը, պետք է նշված լինի Vary-ում, այլապես քեշը կարող է Brotli body մատուցել client-ին, որն ընդունում է միայն gzip, կամ ռուսերեն էջ՝ անգլիախոս այցելուին։ Vary-ն նաև բաժանում է քեշը. Vary: User-Agent-ը կամ Vary: Cookie-ն կարող են քեշավորումը գրեթե անօգուտ դարձնել, ուստի լեզուների համար նախընտրեք առանձին URL-ներ, իսկ Vary-ն հնարավորության դեպքում սահմանափակեք Accept-Encoding-ով։ Range request-ները թույլ են տալիս client-ին խնդրել ֆայլի մի մասը Range: bytes=0-1023-ով. սերվերը պատասխանում է 206 Partial Content և աջակցությունը հայտարարում է Accept-Ranges: bytes-ով։ Video player-ները և download manager-ները սրանից են կախված seek-ի և ընդհատված ներբեռնումը շարունակելու համար։

1curl -s -o /dev/null -D - -H "Range: bytes=0-1023" https://example.com/video.mp4
2# HTTP/2 206
3# content-range: bytes 0-1023/48213004
4# accept-ranges: bytes

11Cookie-ներ կայքերի, subdomain-ների և frame-երի միջև

Site-ը և origin-ը տարբեր գաղափարներ են։ Origin-ը scheme + host + port է, site-ը registrable domain-ն է, ուստի app.example.com-ը և api.example.com-ը տարբեր origin-ներ են, բայց նույն site-ը։ SameSite կանոններն օգտագործում են site-երը, ահա թե ինչու SameSite=Lax cookie-ն դեռ ուղարկվում է ձեր subdomain-ների միջև։ Cross-site դեպքում Lax cookie-ները գնում են միայն top-level GET նավիգացիաների հետ, երբեք՝ այլ կայքից fetch-ի կամ form POST-ի հետ։ Domain attribute-ով սահմանված cookie-ները կիսվում են բոլոր subdomain-ների հետ, ներառյալ third-party ծառայության կողմից աշխատեցվողները, ուստի session cookie-ները պահեք host-only։ Third-party կոնտեքստները սահմանափակված են. Safari-ն և Firefox-ը լռելյայն արգելափակում են third-party cookie-ները, իսկ Partitioned cookie-ները (CHIPS) թույլ են տալիս ներդրված widget-ին վիճակը պահել առանձին՝ յուրաքանչյուր top-level site-ի համար։ Բրաուզերները նաև սահմանափակում են cookie-ի չափը՝ մոտ 4 KB յուրաքանչյուրը, և ամեն cookie ուղարկվում է ամեն հարցման հետ, ուստի մեծ cookie-ները bandwidth են ծախսում։

1Set-Cookie: __Host-sid=8f2c...; Path=/; Secure; HttpOnly; SameSite=Lax
2Set-Cookie: widget_state=abc; Path=/; Secure; SameSite=None; Partitioned