RFC 2068. Protokol peredachi giperteksta -- HTTP/1.1 (perevod)
Network Working Group R. Fielding
Request for Comments: 2068 UC Irvine
Category: Standards Track J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
YAnvar' 1997
PROTOKOL PEREDACHI GIPERTEKSTA -- HTTP/1.1
O perevode.
|des' predstavlen perevod dokumenta RFC 2068 na russkij yazyk. Pri
perevode ya pol'zovalsya lichnym opytom i zdravym smyslom, poetomu v
nekotoryh mestah chitatel', znakomyj s originalom, mozhet zametit'
nesushchestvennye otlichiya. YA izo vseh sil pytalsya pridat' udobochitaemyj
vid, no v nekotoryh mestah vy vstretite predlozheniya, napisannye
"krivo" (eto svyazano libo s "tehnichnost'yu" teksta, libo s moimi
problemami v russkom yazyke). Ubeditel'naya pros'ba : esli
vstretite opechatki, oshibki, ili u vas poyavyatsya predlozheniya po
uluchsheniyu otdel'nyh fraz ili celyh fragmentov - soobshchite mne po
adresu Leshik@omsk.com .
YA otdayu sebe otchet v tom, chto nekotorye terminy, vozmozhno,
perevedeny nekorrektno. Pri somneniyah ya dobavlyal anglijskie terminy
v kruglyh skobkah. Naprimer: zapros (request).
V soderzhanii ukazany stranicy anglijskogo originala.
|tim perevodom ya ne presledoval kommercheskih celej, poetomu ya ne
nesu otvetstvennosti za nesootvetstvie russkogo perevoda
anglijskomu originalu. Esli Vy zhelaete poluchit' adekvatnyj perevod
etogo dokumenta (ili kakogo-libo drugogo po komp'yuternoj tematike),
to ya mogu ego pererabotat' v sootvetstvii s Vashimi trebovaniyami za
opredelennuyu platu (eto svyazano s moim tyazhelym finansovym polozheniem
kak studenta).
Aleksej Simonov.
Status dannogo dokumenta.
|tot dokument opredelyaet protokol dorozhki standartov Interneta
(Internet standards track protocol) dlya semejstva Interneta, i
prednaznachen dlya obsuzhdeniya i predlozhenij po usovershenstvovaniyu.
Pozhalujsta obratites' k tekushchemu izdaniyu "Oficial'nyh standartov
protokolov Internet" (STD 1) dlya vyyasneniya sostoyaniya standartizacii
i statusa etogo protokola. Rasprostranenie dannogo dokumenta
neogranicheno.
Referat.
Protokol peredachi Giperteksta (HTTP) - protokol prikladnogo urovnya
dlya raspredelennyh, sovmestnyh, mnogosrednyh informacionnyh sistem.
|to obshchij, platformno-nezavisimyj, ob容ktno-orientirovannyj protokol,
kotoryj mozhet ispol'zovat'sya vo mnogih zadachah, takih kak servera
imen i raspredelennye sistemy upravleniya ob容ktami, posredstvom
rasshireniya metodov zaprosa.
Vozmozhnost' HTTP - eto pechat' i obsuzhdenie predstavleniya dannyh,
pozvolyayushchee stroit' sistemy nezavisimo ot peredavaemyh dannyh.
HTTP ispol'zuetsya v World Wide Web (WWW) nachinaya s 1990 goda. |ta
specifikaciya opredelyaet protokol, upominaemyj kak "HTTP/1.1".
Soderzhanie.
1 Vvedenie ................................................7
1.1 Cel' .................................................7
1.2 Trebovaniya ...........................................7
1.3 Terminologiya .........................................8
1.4 Obshchee opisanie ......................................11
2 Pis'mennye soglasheniya i obobshchennaya grammatika ..........13
2.1 Uvelichennaya normal'naya zapis' Bekusa-Naura (BNF) ....13
2.2 Osnovnye pravila ....................................15
3 Parametry protokola ....................................17
3.1 Versiya HTTP .........................................17
3.2 Universal'nye Identifikatory Resursov (URI) .........18
3.2.1 Obshchij sintaksis ..................................18
3.2.2 HTTP URL .........................................19
3.2.3 Sravnenie URI ....................................20
3.3 Formaty daty/vremeni ................................21
3.3.1 Polnaya data ......................................21
3.3.2 Raznost' sekund (delta seconds) ..................22
3.4 Kodovye tablicy (character sets) ....................22
3.5 Kodirovanie soderzhimogo (content codings) ...........23
3.6 Kodirovanie peredachi (transfer codings) .............24
3.7 Media tipy (Media Types) ............................25
3.7.1 Kanonizaciya i predopredelennye znacheniya tipa
text .............................................26
3.7.2 Tipy Multipart ...................................27
3.8 Leksemy programm (Product Tokens) ...................28
3.9 Kachestvennye znacheniya (Quality Values) ..............28
3.10 Metki yazykov (Language Tags) .......................28
3.11 Metki ob容ktov (Entity Tags) .......................29
3.12 Edenicy izmereniya diapazonov (Range Units) .........30
4 HTTP soobshchenie (HTTP Message) ..........................30
4.1 Tipy soobshchenij ......................................30
4.2 Zagolovki soobshchenij .................................31
4.3 Telo coobshcheniya ......................................32
4.4 Dlina soobshcheniya .....................................32
4.5 Obshchie polya zagolovka ................................34
5 Zapros (Request) .......................................34
5.1 Stroka zaprosa (Request-Line) .......................34
5.1.1 Metod (Method) ...................................35
5.1.2 Zaprashivaemyj URI (Request-URI) ..................35
5.2 Resurs, identificiruemyj zaprosom ...................37
5.3 Polya zagolovka zaprosa ..............................37
6 Otvet (Response) .......................................38
6.1 Stroka sostoyaniya (Status-Line) ......................38
6.1.1 Kod sostoyaniya i poyasnyayushchaya fraza .................39
6.2 Polya zagolovka otveta ...............................41
7 Ob容kt (Entity) ........................................41
7.1 Polya zagolovka ob容kta ..............................41
7.2 Telo ob容kta ........................................42
7.2.1 Tip (Type) .......................................42
7.2.2 Dlina (Length) ...................................43
8 Soedineniya (Connections) ...............................43
8.1 Postoyannye soedineniya (Persistent Connections) ......43
8.1.1 Cel' .............................................43
8.1.2 Obshchee opisanie ...................................44
8.1.3 Proksi-servera (Proxy Servers) ...................45
8.1.4 Prakticheskie coglasheniya ..........................45
8.2 Trebovaniya k peredache soobshchenij .....................46
9 Opredeleniya metodov (Method Definitions) ...............48
? 9.1 Bezopasnye i Idempotent Metody ......................48
9.1.1 Bezopasnye metody ................................48
? 9.1.2 Idempotent metody (Idempotent Methods) ...........49
9.2 OPTIONS .............................................49
9.3 GET .................................................50
9.4 HEAD ................................................50
9.5 POST ................................................51
9.6 PUT .................................................52
9.7 DELETE ..............................................53
9.8 TRACE ...............................................53
10 Opisaniya kodov sostoyaniya ..............................53
10.1 1xx - Informacionnye kody ..........................54
10.1.1 100 Prodolzhat', Continue ........................54
10.1.2 101 Pereklyuchenie protokolov, Switching
Protocols ...................................54
10.2 2xx - Uspeshnye kody ................................54
10.2.1 200 OK ..........................................54
10.2.2 201 Sozdan, Created .............................55
10.2.3 202 Prinyato, Accepted ...........................55
10.2.4 203 Ne avtorskaya informaciya, Non-Authoritative
Information .................................55
10.2.5 204 Net soderzhimogo, No Content .................55
10.2.6 205 Sbrosit' soderzhimoe, Reset Content ..........56
10.2.7 206 CHastichnoe soderzhimoe, Partial Content .......56
10.3 3xx - Kody perenapravleniya .........................56
10.3.1 300 Mnozhestvennyj vybor, Multiple Choices .......57
10.3.2 301 Postoyanno perenesen, Moved Permanently ......57
10.3.3 302 Vremenno peremeshchen, Moved Temporarily .......58
10.3.4 303 Smotret' drugoj, See Other ..................58
10.3.5 304 Ne modificirovan, Not Modified ..............58
10.3.6 305 Ispol'zujte proksi-server, Use Proxy ........59
10.4 4xx - Kody oshibok klienta ..........................59
10.4.1 400 Isporchennyj Zapros, Bad Request .............60
10.4.2 401 Nesankcionirovanno, Unauthorized ............60
10.4.3 402 Trebuetsya oplata, Payment Required ..........60
10.4.4 403 Zapreshcheno, Forbidden ........................60
10.4.5 404 Ne najden, Not Found ........................60
10.4.6 405 Metod ne dozvolen, Method Not Allowed .......61
10.4.7 406 Ne priemlem, Not Acceptable .................61
10.4.8 407 Trebuetsya ustanovlenie podlinnosti cherez
proksi-server, Proxy Authentication
Required ....................................61
10.4.9 408 Isteklo vremya ozhidaniya zaprosa, Request
Timeout .....................................62
10.4.10 409 Konflikt, Conflict .........................62
10.4.11 410 Udalen, Gone ...............................62
10.4.12 411 Trebuetsya dlina, Length Required ...........63
10.4.13 412 Preduslovie neverno, Precondition Failed ...63
10.4.14 413 Ob容kt zaprosa slishkom bol'shoj, Request
Entity Too Large ...........................63
10.4.15 414 URI zaprosa slishkom dlinnyj, Request-URI
Too Long ...................................63
10.4.16 415 Nepodderzhivaemyj media tip, Unsupported
Media Type .................................63
10.5 5xx - Kody oshibok servera ..........................64
10.5.1 500 Vnutrennyaya oshibka servera, Internal Server
Error .......................................64
10.5.2 501 Ne realizovano, Not Implemented .............64
10.5.3 502 Oshibka shlyuza, Bad Gateway ...................64
10.5.4 503 Servis nedostupen, Service Unavailable ......64
10.5.5 504 Isteklo vremya ozhidaniya ot shlyuza, Gateway
Timeout .....................................64
10.5.6 505 Ne podderzhivaemaya versiya HTTP, HTTP Version
Not Supported ...............................65
11 Ustanovlenie podlinnosti dostupa (Access
Authentication) .......................................65
11.1 Bazovaya shema ustanovleniya podlinnosti (Basic
Authentication Scheme) .............................66
11.2 Obzornaya shema ustanovleniya podlinnosti (Digest
Authentication Scheme) .............................67
12 Obsuzhdenie soderzhimogo (Content Negotiation) ..........67
12.1 Upravlyaemoe serverom obsuzhdenie ....................68
12.2 Upravlyaemoe agentom obsuzhdenie .....................69
12.3 Prozrachnoe obsuzhdenie ..............................70
13 Keshirovanie v HTTP ....................................70
13.1.1 Pravil'nost' keshirovaniya ........................72
13.1.2 Preduprezhdeniya ..................................73
13.1.3 Mehanizmy upravleniya keshem ......................74
13.1.4 YAvnye preduprezhdeniya User Agent .................74
13.1.5 Isklyucheniya iz pravil i preduprezhdenij ...........75
13.1.6 Kontrolliruemoe klientom povedenie ..............75
13.2 Model' ustarevaniya .................................75
13.2.1 Ustarevanie, opredeleyaemoe serverom .............75
13.2.2 |vristicheskoe ustarevanie .......................76
13.2.3 Vychislenie vozrasta .............................77
13.2.4 Vychislenie ustarevanie ..........................79
13.2.5 Znacheniya odnoznachnogo ustarevaniya ...............80
13.2.6 Disambiguating Multiple Responses ...............80
13.3 Model' sravneniya (validation model) ................81
13.3.1 Daty poslednego izmeneniya (Last-modified Dates)..82
13.3.2 Ob容ktnye otmetki sravneniya kesha ................82
13.3.3 Slaboe i sil'noe sravnenie ......................82
13.3.4 Pravila kogda ispol'zovat' ob容ktnye otmetki
(Entity Tags) i daty poslednego izmeneniya (Last-
modified Dates).........................................85
13.3.5 Neproveryaemye usloviya ...........................86
13.4 Cachability otveta .................................86
13.5 Postroenie otvetov iz keshej ........................87
13.5.1 Skvoznye (End-to-end) i promezhutochnye (Hop-by-hop)
zagolovki ..............................................88
13.5.2 Nemodificiruemye zagolovki ......................88
13.5.3 Ob容dinenie zagolovkov ..........................89
13.5.4 Ob容dinnenie diapazonov bajtov ..................90
13.6 Keshirovanie peregovornyh otvetov (Negotiated
Responses)...............................................90
13.7 Obshchedostupnye i neobshchedostupnye keshi ...............91
13.8 Povedenie kesha pri oshibochnyh ili nezavershennyh
otvetah .................................................91
13.9 Pobochnye effekty GET i HEAD ........................92
13.10 Oshibki posle modifikacij ili stiraniya .............92
13.11 Write-Through Mandatory ...........................93
13.12 Zamena kesha .......................................93
13.13 Spiski history ....................................93
14 Opredeleniya polej zagolovka ...........................94
14.1 Accept .............................................95
14.2 Accept-Charset .....................................97
14.3 Accept-Encoding ....................................97
14.4 Accept-Language ....................................98
14.5 Accept-Ranges ......................................99
14.6 Age ................................................99
14.7 Allow .............................................100
14.8 Authorization .....................................100
14.9 Cache-Control .....................................101
14.9.1 CHto keshiruemo (Cachable) .......................103
14.9.2 CHto mozhet byt' sohraneno keshem .................103
14.9.3 Modifikacii osnovnogo mehanizma ustarevaniya ....104
14.9.4 Pereproverki pravil'nosti kesha i sredstva
upravleniya perezagruzkoj ..............................105
14.9.5 Direktiva No-Transform .........................107
14.9.6 Rasshireniya sredstv upravleniya keshem ............108
14.10 Connection .......................................109
14.11 Content-Base .....................................109
14.12 Content-Encoding .................................110
14.13 Content-Language .................................110
14.14 Content-Length ...................................111
14.15 Content-Location .................................112
14.16 Content-MD5 ......................................113
14.17 Content-Range ....................................114
14.18 Content-Type .....................................116
14.19 Date .............................................116
14.20 ETag .............................................117
14.21 Expires ..........................................117
14.22 From .............................................118
14.23 Host .............................................119
14.24 If-Modified-Since ................................119
14.25 If-Match .........................................121
14.26 If-None-Match ....................................122
14.27 If-Range .........................................123
14.28 If-Unmodified-Since ..............................124
14.29 Last-Modified ....................................124
14.30 Location .........................................125
14.31 Max-Forwards .....................................125
14.32 Pragma ...........................................126
14.33 Proxy-Authenticate ...............................127
14.34 Proxy-Authorization ..............................127
14.35 Public ...........................................127
14.36 Range ............................................128
14.36.1 Diapazony bajt (byte ranges) ..................128
14.36.2 Zaprosy diapazonov (Range Retrieval
Requests) .............................................130
14.37 Referer ..........................................131
14.38 Retry-After ......................................131
14.39 Server ...........................................132
14.40 Transfer-Encoding ................................132
14.41 Upgrade ..........................................132
14.42 User-Agent .......................................134
14.43 Vary .............................................134
14.44 Via ..............................................135
14.45 Warning ..........................................137
14.46 WWW-Authenticate .................................139
15 Polozheniya o zashchite ...................................139
15.1 Ustanovleniya podlinnosti klientov .................139
15.2 Predlozhenie vybrat' shemu ustanovleniya
podlinnosti.............................................140
15.3 Nepravil'noe obrashchenie s informaciej fajla
registracii servera (Log)...............................141
15.4 Peredacha chuvstvitel'noj (sensitive) informacii ....141
15.5 Ataki, osnovannye imenah fajlov i putej............142
15.6 Personal'naya informaciya ...........................143
15.7 Problemy sekretnosti, svyazannye s Accept
zagolovkami ............................................143
15.8 Podmena DNS-adresov (DNS Spoofing).................144
15.9 Raspolozhenie zagolovkov i Spoofing ................144
16 Podtverzhdeniya ........................................144
17 Ssylki ...............................................146
18 Adresa avtorov .......................................149
19 Prilozheniya ...........................................150
19.1 Media tip Internet message/http ...................150
19.2 Media tip Internet multipart/byteranges ...........150
19.3 Dopustimye prilozheniya .............................151
19.4 Razlichiya mezhdu HTTP ob容ktami i MIME ob容ktami ....152
19.4.1 Preobrazovanie k kanonicheskoj forme ............152
19.4.2 Preobrazovanie formatov dat ....................153
19.4.3 Vvedenie Content-Encoding ......................153
19.4.4 Nikakogo Content-Transfer-Encoding .............153
19.4.5 Polya HTTP zagolovka v Multipart Body-Parts .....153
19.4.6 Vvedenie Transfer-Encoding .....................154
19.4.7 Versiya MIME ....................................154
19.5 Izmeneniya posle HTTP/1.0 ..........................154
19.5.1 Izmeneniya uproshchaushchie mnogo-homed servera i
sohranyayushchie IP adresa .................................155
19.6 Dopolnitel'nye vozmozhnosti ........................156
19.6.1 Dopolnitel'nye metody zaprosov .................156
19.6.2 Dopolnitel'nye opredeleniya polej zagolovka .....156
19.7 Sovmestimost' s predydushchimi versiyami ..............160
19.7.1 Sovmestimost' s postoyannymi soedineniyami,
opredelyaemymi HTTP/1.0 ...............................161
Protokol peredachi Giperteksta (HTTP) - protokol prikladnogo urovnya
dlya raspredelennyh, sovmestnyh, mnogosrednyh informacionnyh sistem.
HTTP ispol'zuetsya v World Wide Web (WWW) nachinaya s 1990 goda. Pervoj
versiej HTTP, izvestnoj kak HTTP/0.9, byl prostoj protokol dlya
peredachi neobrabotannyh dannyh cherez Internet. HTTP/1.0, kak
opredeleno v RFC 1945 [6], byl uluchsheniem etogo protokola, pozvolyaya
soobshcheniyam imet' MIME-podobnyj format, soderzhashchij metainformaciyu o
peredavaemyh dannyh i imel modificirovannuyu semantiku
zaprosov/otvetov. Odnako, HTTP/1.0 nedostatochno horosho uchityval
osobennosti raboty s ierarhicheskimi proksi-serverami (hierarchical
proxies), keshirovaniem, postoyannymi soedineniyami, i virtual'nymi
hostami (virtual hosts). Krome togo, bystroe uvelichenie ne polnost'yu
sovmestimyh prilozhenij, nazyvayushchih tot protokol, kotoryj oni
ispol'zovali "HTTP/1.0", potrebovalo vvedeniya versii protokola, v
kotoroj byli by zalozheny vozmozhnosti, pozvolyayushchie prilozheniyam
opredelyat' istinnye vozmozhnosti drug druga.
|ta specifikaciya opredelyaet protokol "HTTP/1.1". |tot protokol
soderzhit bolee strogie trebovaniya, chem HTTP/1.0, garantiruyushchie
nadezhnuyu realizaciyu vozmozhnostej.
Prakticheski informacionnye sistemy trebuyut bol'shej funkcional'nosti,
chem prosto zagruzku informacii, vklyuchaya poisk, modifikaciyu pri
pomoshchi vneshnego interfejsa, i annotaciyu (annotation). HTTP
predostavlyaet otkrytyj nabor metodov, kotorye ukazyvayut cel' zaprosa.
Oni osnovany na discipline ssylki, obespechennoj Universal'nym
Identifikatorom Resursa (URI) [3][20], kak raspolozhenie (URL) [4]
ili imya (URN), dlya identifikacii resursa, k kotoromu etot metod
primenyaetsya. Soobshcheniya peredayutsya v formate, podobnom ispol'zuemomu
elektronnoj pochtoj, kak opredeleno Mnogocelevymi Rasshireniyami
|lektronnoj Pochty (MIME).
HTTP takzhe ispol'zuetsya kak obobshchennyj protokol svyazi mezhdu agentami
pol'zovatelej i proksi-serverami/shlyuzami (proxies/gateways) ili
drugimi servisami Interneta, vklyuchaya takie, kak SMTP [16], NNTP [13],
FTP [18], Gopher [2], i WAIS [10]. Takim obrazom, HTTP zakladyvaet
osnovy mnogosrednogo (hypermedia) dostupa k resursam dlya
raznoobraznyh prilozhenij.
|ta specifikaciya ispol'zuet te zhe samye slova dlya opredeleniya
trebovanij k realizacii protokola, chto i RFC 1123 [8]. |ti slova
sleduyushchie:
NEOBHODIMO, DOLZHEN (MUST)
Primenyaetsya dlya ukazaniya, chto dannoe trebovanie specifikacii
neobhodimo obespechit' v lyubom sluchae.
REKOMENDUETSYA, SLEDUET (SHOULD)
Ispol'zuetsya dlya ukazaniya, chto dannoe trebovanie specifikacii
dolzhno byt' obespecheno, esli etomu ne prepyatstvuyut ser'eznye
prichiny.
VOZMOZHNO, MOZHET (MAY)
Ispol'zuetsya dlya ukazaniya, chto dannoe trebovanie specifikacii
yavlyaetsya opcional'nym i mozhet byt' libo realizovano, libo net -
po neobhodimosti.
Realizaciya schitaetsya nesovmestimoj, esli narusheno hotya by odno
NEOBHODIMYH trebovanij specifikacii protokola. Realizaciya,
udovletvoryayushchaya vsem NEOBHODIMYM i REKOMENDUEMYM tredovaniyam
nazyvaetsya polnost'yu sovmestimoj, a udovletvoryayushchaya vsem NEOBHODIMYM,
no ne vsem REKOMENDUEMYM trebovaniyam nazyvaetsya uslovno sovmestimoj.
|ta specifikaciya ispol'zuet ryad terminov dlya opisaniya roli
uchastnikov, nekotoryh ob容ktov, i HTTP svyazi.
Soedinenie (connection)
Virtual'nyj kanal transportogo urovnya, ustanovlennyj mezhdu dvumya
programmami s cel'yu svyazi.
Soobshchenie (message)
Osnovnoj modul' HTTP svyazi, sostoyashchej iz strukturnoj
posledovatel'nosti oktetov, sootvetstvuyushchih sintaksisu,
opredelennomu v razdele 4 i peredavaemyh po soedineniyu.
Zapros (request)
Lyuboe HTTP soobshchenie, soderzhashchee zapros, opredelyaemyj v razdele 5.
Otvet (response)
Lyuboe HTTP soobshchenie, soderzhashchee otvet, opredelyaemyj v razdele 5.
Resurs (resource)
Setevoj ob容kt dannyh ili servis, kotoryj mozhet byt'
identificirovan URI, opredelelyaemym v razdele 3.2. Resursy mogut
byt' dostupny v neskol'kih predstavleniyah (naprimer na neskol'kih
yazykah, v raznyh formatah dannyh, imet' razlichnyj razmer, imet'
razlichnuyu razreshayushchuyu sposobnost') ili razlichat'sya po drugim
parametram.
Ob容kt (entity)
Informaciya, peredavaemaya v kachestve poleznoj nagruzki zaprosa ili
otveta. Ob容kt sostoit iz metainformacii v forme polej zagolovka
ob容kta i soderzhaniya v forme tela ob容kta, kak opisano v razdele
7.
Predstavlenie (representation)
Ob容kt vklyuchennyj v otvet, i podchinyayushchijsya obsuzhdeniyu
soderzhimogo (Content Negotiation), chto opisano v razdele 12.
Mozhet sushchestvovat' neskol'ko predstavlenij, svyazannyh so
specificheskimi sostoyaniyami otveta.
Obsuzhdenie soderzhimogo (content negotiation)
Mehanizm dlya vybora sootvetstvuyushchego predstavleniya vo vremya
obsluzhivaniya zaprosa, kak opisano v razdele 12. Predstavlenie
ob容ktov v lyubom otvete mozhet byt' obsuzhdeno (vklyuchaya oshibochnye
otvety).
Variant (variant)
Resurs mozhet imet' odno, ili neskol'ko predstavlenij, svyazannyh
s nim v dannyj moment. Kazhdoe iz etih predstavlenij nazyvaetsya
"variant". Ispol'zovanie termina "variant" ne obyazatel'no
podrazumevaet, chto resurs podchinen obsuzhdeniyu soderzhimogo.
Klient (client)
Programma, kotoraya ustanavlivaet soedineniya s cel'yu posylki
zaprosov.
Agent pol'zovatelya (user agent)
Klient, kotoryj iniciiruet zapros. Kak pravilo brauzery,
redaktory, roboty (spiders), ili drugie instrumental'nye
sredstva pol'zovatelya.
Server (server)
Prilozhenie, kotoroe slushaet soedineniya, prinimaet zaprosy na
obsluzhivanie i posylaet otvety. Lyubaya takaya programma sposobna
byt' kak klientom, tak i serverom; nashe ispol'zovanie dannogo
termina otnositsya skoree k roli, kotoruyu programma vypolnyaet,
sozdavaya specificheskie soedineniya, nezheli k vozmozhnostyam
programmy voobshche. Analogichno, lyuboj server mozhet dejstvovat' kak
pervonachal'nyj server, proksi-server, shlyuz, ili tunnel' (tunnel),
izmenyaya povedenie, osnovyvayas' na haraktere kazhdogo zaprosa.
Pervonachal'nyj server (origin server)
Server, na kotorom dannyj resurs postoyanno nahoditsya ili dolzhen
byt' sozdan.
Proksi-server (proxy)
Programma-posrednik, kotoraya dejstvuet i kak server, i kak
klient s cel'yu sozdaniya zaprosov ot imeni drugih klientov.
Zaprosy obsluzhivayutsya proksi-serverom, ili peredayutsya im,
vozmozhno s izmeneniyami. Proksi-server dolzhen udovletvoryat'
trebovaniyam klienta i servera, soglasno etoj specifikacii.
SHlyuz (gateway)
Server, kotoryj dejstvuet kak posrednik dlya nekotorogo
drugogo servera. V otlichie ot proksi-servera, shlyuz poluchaet
zaprosy v kachestve pervonachal'nogo servera dlya zaproshennogo
resursa; klient zaprosa mozhet ne znat', chto on soedinyaetsya so
shlyuzom.
Tunnel' (tunnel)
Programma-posrednik, kotoraya podderzhivaet soedinenie. Odin
raz sozdannyj, tunnel' ne rassmatrivaetsya kak chast' HTTP svyazi,
hotya tunnel', vozmozhno, byl inicializirovan zaprosom HTTP.
Tunnel' prekrashchaet sushchestvovat', kogda oba konca soedineniya
zakryvayutsya.
Kesh (cache)
Lokal'naya pamyat', v kotoroj programma hranit soobshcheniya otvetov,
i v kotoroj raspolagaetsya podsistema, upravlyayushchaya hraneniem,
poiskom i stiraniem soobshchenij. Kesh sohranyaet otvety, kotorye
mogut byt' sohraneny, chtoby umen'shit' vremya otveta i zagruzku
seti (traffik) pri budushchih ekvivalentnyh zaprosah. Lyuboj klient
ili server mozhet imet' kesh, no kesh ne mozhet ispol'zovat'sya
serverom, kotoryj dejstvuet kak tunnel'.
Keshiruemyj (cachable)
Otvet yavlyaetsya keshiruemym, esli keshu razresheno sohranit' kopiyu
otvetnogo soobshcheniya dlya ispol'zovaniya pri otvete na posleduyushchie
zaprosy. Pravila dlya opredeleniya keshiruemosti HTTP otvetov
opredeleny v razdele 13. Dazhe esli resurs keshiruem, mogut
sushchestvovat' dopolnitel'nye ogranicheniya na ispol'zovanie keshem
sohranennoj kopii dlya shodnogo zaprosa.
Neposredstvennyj (first-hand)
Otvet schitaetsya neposredstvennym, esli on prihodit
neposredstvenno ot pervonachal'nogo servera bez nenuzhnoj zaderzhki,
vozmozhno cherez odin ili neskol'ko proksi-serverov. Otvet takzhe
yavlyaetsya neposredstvennym, esli ego pravil'nost' tol'ko chto byla
proverena neposredstvenno pervonachal'nym serverom.
Tochnoe vremya ustarevaniya (explicit expiration time)
Vremya, opredelennoe pervonachal'nym serverom i pokazyvayushchee keshu,
kogda ob容kt bol'she ne mozhet byt' vozvrashchen keshem klientu bez
dopolnitel'noj proverki pravil'nosti.
|vristicheskoe vremya ustarevaniya (heuristic expiration time)
Vremya ustarevaniya, naznachennoe keshem, esli ne ukazano tochnoe
vremya ustarevaniya.
Vozrast (age)
Vozrast otveta - vremya, proshedshee s momenta otsylki, ili
uspeshnoj proverki otveta pervonachal'nym serverom.
Vremya zhizni (freshness lifetime)
Otrezok vremeni mezhdu porozhdeniem otveta i vremenem ustarevaniya.
Svezhij (fresh)
Otvet schitaetsya svezhim, esli ego vozrast eshche ne prevysil vremya
zhizni.
Prosrochennnyj (stale)
Otvet schitaetsya prosrochennym, esli ego vozrast prevysil vremya
zhizni.
Semanticheski prozrachnyj (semantically transparent)
Govoryat, chto kesh vedet sebya "semanticheski prozrachnym" obrazom v
otnoshenii specificheskogo otveta, kogda ispol'zovanie kesha ne
vliyaet ni na klienta zaprosa, ni na pervonachal'nyj server, no
povyshaet effektivnost'. Kogda kesh semanticheski prozrachen, klient
poluchaet tochno takoj zhe otvet (za isklyucheniem promezhutochnyh
(hop-by-hop) zagolovkov), kotoryj poluchil by, zaprashivaya
neposredstvenno pervonachal'nyj server, a ne kesh.
? Ukazatel' pravil'nosti (validator)
|lement protokola (naprimer, metka ob容kta ili vremya poslednej
modifikacii (Last-Modified time)), kotoryj ispol'zuetsya, chtoby
vyyasnit', yavlyaetsya li nahodyashchayasya v keshe kopiya ekvivalentom
ob容kta.
Protokol HTTP - eto protokol zaprosov/otvetov. Klient posylaet
serveru zapros, soderzhashchij metod zaprosa, URI, versiyu protokola,
MIME-podobnoe soobshchenie, soderzhashchee modifikatory zaprosa, klientskuyu
informaciyu, i, vozmozhno, telo zaprosa, po soedineniyu. Server
otvechaet strokoj sostoyaniya, vklyuchayushchej versiyu protokola soobshcheniya,
kod uspeshnogo vypolneniya ili kod oshibki, MIME-podobnoe soobshchenie,
soderzhashchee informaciyu o servere, metainformaciyu ob容kta, i,
vozmozhno, telo ob容kta. Svyaz' mezhdu HTTP i MIME opisana v prilozhenii
19.4.
Bol'shinstvo HTTP soedinenij inicializiruetsya agentom pol'zovatelya i
sostoit iz zaprosa, kotoryj nuzhno primenit' k resursu na nekotorom
pervonachal'nom servere. V samom prostom sluchae, on mozhet byt'
vypolnen posredstvom odinochnogo soedineniya (v) mezhdu agentom
pol'zovatelya (UA) i pervonachal'nym serverom (O).
cepochka zaprosov --------------------->
UA -------------------v------------------- O
<----------------------- cepochka otvetov
Bolee slozhnaya situaciya voznikaet, kogda v cepochke zaprosov/otvetov
prisutstvuet odin ili neskol'ko posrednikov. Sushchestvuyut tri
osnovnyh raznovidnosti posrednikov: proksi-servera, shlyuzy, i
tunneli. Proksi-server yavlyaetsya agentom-posrednikom, kotoryj
poluchaet zaprosy na nekotoryj URI v absolyutnoj forme, izmenyaet vse
soobshchenie ili ego chast', i otsylaet izmenennyj zapros serveru,
identificirovannomu URI. SHlyuz - eto prinimayushchij agent, dejstvuyushchij
kak by uroven' vyshe nekotorogo drugogo servera(ov) i, v sluchae
neobhodimosti, transliruyushchij zaprosy v protokol osnovnogo servera.
Tunnel' dejstvuet kak rele mezhdu dvumya soedineniyami ne izmenyaya
soobshcheniya; tunneli ispol'zuyutsya, kogda svyaz' nuzhno proizvodit'
cherez posrednika (naprimer Firewall), kotoryj ne ponimaet
soderzhanie soobshchenij.
cepochka zaprosov ----------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------ cepochka otvetov
Na poslednem risunke pokazany tri posrednika (A, B, i C) mezhdu
agentom pol'zovatelya i pervonachal'nym serverom. Zaprosy i otvety
peredayutsya cherez chetyre otdel'nyh soedineniya. |to razlichie vazhno,
tak kak nekotorye opcii HTTP soedineniya primenimy tol'ko k
soedineniyu s blizhajshim ne tunnel'nym sosedom, nekotorye tol'ko k
konechnym tochkam cepochki, a nekotorye ko vsem soedineniyam v cepochke.
Hotya diagramma linejna, kazhdyj uchastnik mozhet byt' zadejstvovan v
neskol'kih soedineniyah odnovremenno. Naprimer, B mozhet poluchat'
zaprosy ot drugih klientov, a ne tol'ko ot A, i/ili peresylat'
zaprosy k serveram, otlichnym ot C, v to zhe vremya, kogda on
obrabatyvaet zapros ot A.
Lyubaya storona soedineniya, kotoraya ne dejstvuet kak tunnel', mozhet
ispol'zovat' vnutrennij kesh dlya obrabotki zaprosov. |ffekt kesha
zaklyuchaetsya v tom, chto cepochka zaprosov/otvetov sokrashchaetsya, esli
odin iz uchastnikov v cepochke imeet keshirovannyj otvet, primenimyj
k dannomu zaprosu. Dalee illyustriruetsya cepochka, voznikayushchaya v
rezul'tate togo, chto B imeet keshirovanuyu kopiyu rannego otveta O
(polechennogo cherez C) dlya zaprosa, i kotoryj ne keshirovalsya ni UA,
ni A.
cepochka zaprosov ------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<-------- cepochka otvetov
Ne vse otvety polezno keshirovat', a nekotorye zaprosy mogut
soderzhat' modifikatory, kotorye vklyuchayut special'nye trebovaniya,
upravlyayushchie povedeniem kesha. Trebovaniya HTTP dlya povedeniya kesha v
otnoshenii keshiruemyh otvetov opredeleny v razdele 13.
Fakticheski, imeetsya shirokoe raznoobrazie arhitektur i konfiguracij
keshej i proksi-serverov, v nastoyashchee vremya razrabatyvaemyh ili
razvernutyh v World Wide Web; eti sistemy vklyuchayut nacional'nye
ierarhii proksi-keshej, kotorye sohranyayut propusknuyu sposobnost'
mezhokeanskih kanalov, sistemy, kotorye rasprostranyayut vo mnogo
mest soderzhimoe kesha, organizacii, kotorye rasprostranyayut
podmnozhestva keshiruemyh dannyh na CD-ROM, i tak dalee. HTTP sistemy
ispol'zuyutsya v korporativnyh intranet-setyah s vysokoskorostnymi
liniyami svyazi, i dlya dostupa cherez PDA s malomoshchnymi liniyami i
neustojchivoj svyazi. Cel' HTTP/1.1 sostoit v podderzhanii shirokogo
mnogoobraziya konfiguracij, uzhe postroennyh pri vvedenii rannih
versij protokola, a takzhe v udovletvorenii potrebnostej
razrabotchikov web prilozhenij, trebuyushchih vysokoj nadezhnosti, po
krajnej mere nadezhnyh otnositel'no indikacii otkaza.
HTTP soedinenie obychno proishodit posredstvom TCP/IP soedinenij.
Zadannyj po umolchaniyu port TCP - 80, no mogut ispol'zovat'sya i
drugie porty. HTTP takzhe mozhet byt' realizovan posredstvom lyubogo
drugogo protokola Interneta, ili drugih setej. HTTP neobhodima
tol'ko nadezhnaya peredacha dannyh, sledovatel'no mozhet ispol'zovat'sya
lyuboj protokol, kotoryj garantiruet nadezhnuyu peredachu dannyh;
otobrazhenie struktury zaprosa i otveta HTTP/1.1 na transportnye
moduli dannyh rassmatrivaemogo protokola - vopros, ne reshaemyj
etoj specifikaciej.
Bol'shinstvo realizacij HTTP/1.0 ispol'zovalo novoe soedinenie dlya
kazhdogo obmena zaprosom/otvetom. V HTTP/1.1, ustanovlennoe
soedinenie mozhet ispol'zovat'sya dlya odnogo ili neskol'kih obmenov
zaprosom/otvetom, hotya soedinenie mozhet byt' zakryto po ryadu
prichin (smotrite razdel 8.1).
2 Pis'mennye soglasheniya i obobshchennaya grammatika.
2.1 Uvelichennaya normal'naya zapis' Bekusa-Naura (BNF).
Vse mehanizmy, opredelennye etim dokumentom, opisany kak v obychnoj,
tak i v uvelichennoj normal'noj zapisi Bekusa-Naura (BNF), podobnoj
ispol'zuemoj v RFC 822 [9]. Razrabotchik dolzhen byt' znakom s takoj
formoj zapisi, chtoby ponyat' dannuyu specifikaciyu. Uvelichennaya
normal'naya zapis' Bekusa-Naura vklyuchaet sleduyushchie konstrukcii:
imya = opredelenie
name = definition
Imya pravila - eto prosto ego nazvanie (ne vklyuchayushchee simvolov
"<" i ">"), i otdelyaemoe ot opredeleniya simvolom ravenstva "=".
Probel vazhen tol'ko pri vyravnivanii prodolzhayushchihsya strok,
ispol'zuemyh dlya ukazaniya opredelenij pravil, kotorye
zanimayut bolee odnoj stroki. Nekotorye osnovnye pravila, takie
kak SP, LWS, HT, CRLF, DIGIT, ALPHA i t.d, predstavleny v
verhnem registre. Uglovye skobki ispol'zuyutsya v opredelenii
vsyakij raz, kogda ih prisutstvie oblegchaet ispol'zovanie imen
pravil.
"literal"
"literal"
Kavychki okruzhayut literal'nyj tekst. Esli ne ustanovleno inogo,
etot tekst registro-nezavisim.
pravilo1 | pravilo2
rule1 | rule2
|lementy, otdelyaemye polosoj ("|") yavlyayutsya variantami. Naprimer,
"da | net" prinimaet znachenie libo da, libo net.
(pravilo1 pravilo2)
(rule1 rule2)
|lementy, vklyuchennye v kruglye skobki obrabatyvayutsya kak
odin element. Takim obrazom, "(elem (foo | bar) elem)"
dopuskaet posledovatel'nosti leksem "elem foo elem" i
"elem bar elem".
*pravilo
*rule
Simvol "*", predshestvuyushchij elementu, ukazyvaet povtorenie.
Polnaya forma - "<n>*<m>element" oznachaet minimum <n>, maksimum
<m> vhozhdenij elementa. Znacheniya po umolchaniyu - 0 i
beskonechnost'. Takim obrazom zapis' "*(element)" dopuskaet
lyuboe chislo povtorenij (v tom chisle nol'); zapis' "1*element"
trebuet po krajnej mere odno povtorenie; a "1*2element"
dopuskaet libo odin, libo dva povtoreniya.
[pravilo]
[rule]
V kvadratnye skobki zaklyuchayut opcional'nye elementy; "[foo bar]"
ekvivalentno "*1(foo bar)".
N pravilo
N rule
Tochnoe kolichestvo povtorenij: "<n>(element)" ekvivalentno
"<n>*<n>(element)"; to est' prisutstvuet tochno <n> povtorov
elementa. Takim obrazom 2DIGIT - nomer iz 2 cifr, a 3ALPHA
- stroka iz treh alfavitnyh simvolov.
#pravilo
#rule
Konstrukciya "#" prednaznachena, podobno "*", dlya opredeleniya
spiska elementov. Polnaya forma - "<n>#<m>element" oznachaet
minimum <n>, maksimum <m> vhozhdenij elementa, otdelennyh odnoj
ili neskol'kimi zapyatymi (","), i, vozmozhno, linejnym probelom
(LWS). |to obychno delaet formu spiskov ochen' prostoj; pravilo
tipa "( *LWS element *( *LWS "," *LWS element)) " mozhno
predstavit' kak "1#element". Vezde, gde ispol'zuetsya eta
konstrukciya, pustye elementy dopuskayutsya, no ne uchityvayutsya pri
podschete predstavlennyh elementov. To est' konstrukciya
"(element), , (element)" dopuskaetsya, no schitayutsya v nej tol'ko
dva elementa. Sledovatel'no tam, gde trebuetsya po krajnej mere
odin element, dolzhen prisutstvovat' po krajnej mere odin ne
pustoj element. Znacheniya po umolchaniyu - 0 i beskonechnost'.
Takim obrazom zapis' "#(element)" dopuskaet lyuboe chislo
povtorenij (v tom chisle nol'); zapis' "1#element" trebuet po
krajnej mere odnogo povtora nenulevogo elementa; a "1*2element"
dopuskaet odin ili dva povtora.
; kommentarij
; comment
Tochka s zapyatoj, postavlennaya sprava ot teksta pravila, nachinaet
kommentarij, kotoryj prodolzhaetsya do konca stroki. |to - prostoj
sposob vklyucheniya poleznyh pometok parallel'no specifikaciyam.
podrazumevaya *LWS
implied *LWS
Grammatika, opisannaya etoj specifikaciej osnovana na slovah.
Za isklyucheniem sluchaev, v kotoryh otmecheno inoe, linejnyj
probel (LWS) mozhet byt' vklyuchen mezhdu lyubymi dvumya smezhnymi
slovami (leksemoj ili strokoj citirovaniya), i mezhdu smezhnymi
leksemami i razdelitelyami (tspecials), ne izmenyaya interpretaciyu
polya. Mezhdu lyubymi dvumya leksemami dolzhen sushchestvovat' po
krajnej mere odin razdelitel' (tspecials), tak kak inache oni
interpretiruyutsya kak odna leksema.
Sleduyushchie pravila ispol'zuyutsya v prodolzhenie vsej etoj specifikacii
dlya opisaniya osnovnyh konstrukcij sintaksicheskogo analiza.
Kodirovannyj nabor simvolov US-ASCII opredelen v ANSI X3.4-1986
[21].
OCTET = <lyubaya 8-bitnaya posledovatel'nost' dannyh>
CHAR = <lyuboj US-ASCII simvol (oktety 0 - 127)>
UPALPHA = <lyuboj US-ASCII simvol verhnego registra
"A".."Z">
LOALPHA = <lyuboj US-ASCII simvol nizhnego registra
"a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <lyubaya US-ASCII cifra "0".."9">
CTL = <lyuboj US-ASCII upravlyayushchij simvol (oktety
0 - 31) i DEL (127)>
CR = <US-ASCII CR, vozvrat karetki (13)>
LF = <US-ASCII LF, perevod stroki (10)>
SP = <US-ASCII SP, probel (32)>
HT = <US-ASCII HT, metka gorizontal'noj
tabulyacii (9)>
<"> = <US-ASCII dvojnye kavychki (34)>
HTTP/1.1 opredelyaet posledovatel'nost' CR LF kak metku konca stroki
vo vseh elementah protokola, za isklyucheniem tela ob容kta (smotrite
prilozhenie 19.3 o dopustimyh primeneniyah (tolerant applications)).
Metka konca stroki vnutri tela ob容kta opredelyaetsya sootvetstvyyushchim
media tipom, kak opisano v razdele 3.7.
CRLF = CR LF
HTTP/1.1 zagolovki zanimayut neskol'ko strok, esli sleduyushchaya stroka
nachinaetsya s probela ili metki gorizontal'noj tabulyacii. Vse
nezapolnennoe prostranstvo stroki, vklyuchaya perehod na sleduyushchuyu
stroku, imeet tu zhe semantiku, chto i SP.
LWS = [CRLF] 1*( SP | HT )
Pravilo TEXT ispol'zuetsya tol'ko dlya opisatel'nogo soderzhimogo polya
i znachenij, kotorye ne prednaznacheny, dlya interpretacii
sintaksicheskim analizatorom soobshchenij. Slova *TEXT mogut soderzhat'
simvoly iz naborov simvolov (character sets), otlichnyh ot
ISO 8859-1 [22], tol'ko kogda oni zakodirovany soglasno pravilam
RFC 1522 [14].
TEXT = <lyuboj OCTET, za isklyucheniem CTLs,
no soderzhashchij LWS>
SHestnadcaterichnye cifry ispol'zuyutsya nekotorymi elementami
protokola.
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Mnogie znacheniya polej zagolovka HTTP/1.1 sostoyat iz slov,
razdelennyh LWS ili special'nymi simvolami. |ti special'nye simvoly
DOLZHNY nahodit'sya v citiruemoj stroke (quoted string), chtoby byt'
ispol'zovannymi v kachestve znacheniya parametra.
token = 1*<lyuboj CHAR za isklyucheniem CTLs ili
tspecials>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
V nekotorye polya HTTP zagolovka mogut byt' vklyucheny kommentarii.
Tekst kommentariya okruzhaetsya kruglymi skobkami. Kommentarii
dopuskayutsya tol'ko v polyah, soderzhashchih "comment" kak chast'
opredeleniya znacheniya polya. Vo vseh drugih polyah kruglye skobki
rassmatrivayutsya chast'yu znacheniya polya.
comment = "(" *( ctext | comment ) ")"
ctext = <lyuboj TEXT ne vklyuchayushchij "(" and ")">
Stroka teksta analiziruetsya kak odno slovo, esli eto citirovanie,
pomechennoe dvojnymi kavychkami.
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <lyuboj TEXT ne vklyuchayushchij <">>
Simvol naklonnoj cherty vlevo ("\") mozhet ispol'zovat'sya kak
odnosimvol'nyj mehanizm citirovaniya tol'ko vnutri konstrukcij
kommentariya i stroki citirovaniya (quoted-string).
quoted-pair = "\" CHAR
HTTP ispol'zuet shemu numeracii tipa "<major>.<minor>", dlya ukazaniya
versii protokola. Strategiya versifikacii protokola prednaznachena
dlya togo, chtoby pozvolit' otpravitelyu ukazat' format soobshcheniya i
svoi sposobnosti ponimaniya dlya dal'nejshej HTTP svyazi, prezhde chem
on poluchit chto-libo posredstvom etoj svyazi. Pri dobavlenii
komponentov soobshcheniya, kotorye ne vozdejstvuyut na povedenie
svyazi, ili komponentov, kotorye dobavlyayutsya tol'ko k rasshiryaemym
znacheniyam polya, nomer versii ne menyaetsya. Kogda vnesennye v protokol
izmeneniya dobavlyayut vozmozhnosti, kotorye ne izmenyayut obshchij algoritm
analiza soobshchenij, no kotorye rasshiryayut semantiku soobshcheniya i
podrazumevayut dopolnitel'nye vozmozhnosti otpravitelya, uvelichivaetsya
<Minor> nomer. Kogda format soobshcheniya protokola izmenyaetsya
uvelichivaetsya <Major> nomer.
Versiya HTTP soobshcheniya oboznachaetsya polem HTTP-version v pervoj
stroke soobshcheniya.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Obratite vnimanie, chto major i minor chisla DOLZHNY obrabatyvat'sya
kak otdel'nye celye chisla i chto kazhdoe mozhet sostoyat' bolee chem iz
odnoj cifry. Takim obrazom, HTTP/2.4 - bolee nizkaya versiya, chem
HTTP/2.13, kotoraya v svoyu ochered' nizhe chem HTTP/12.3. Nuli DOLZHNY
ignorirovat'sya poluchatelyami i NE DOLZHNY posylat'sya.
Prilozheniya, posylayushchie soobshcheniya zaprosov ili otvetov, kotorye
opisyvaet eta specifikaciya, DOLZHNY vklyuchit' HTTP versiyu
(HTTP-version) "HTTP/1.1". Ispol'zovanie etogo nomera versii
ukazyvaet, chto posylayushchee prilozhenie po krajnej mere uslovno
sovmestimo s etoj specifikaciej.
HTTP versiya prilozheniya - eto samaya vysokaya HTTP versiya, dlya kotoroj
prilozhenie yavlyaetsya po krajnej mere uslovno sovmestimym.
Prilozheniya, realizuyushchie proksi-servera i shlyuzy, dolzhny byt'
vnimatel'ny, kogda peresylayut soobshcheniya protokola razlichnyh versij.
Nachinaya s momenta, kogda versiya protokola ukazyvaet vozmozhnosti
otpravitelya, proksi-server/shlyuz nikogda NE DOLZHEN posylat'
soobshcheniya, versiya kotoryh bol'she, chem HTTP versiya otpravitelya; esli
poluchena bolee vysokaya versiya zaprosa, to proksi-server/shlyuz DOLZHEN
ili ponizit' versiyu zaprosa, otdav soobshchenie ob oshibke, ili
pereklyuchit'sya na tunnel'noe povedenie. U zaprosov, versiya kotoryh
nizhe, chem HTTP versiya proksi-servera/shlyuza MOZHNO pered peresylkoj
uvelichit' versiyu; otvet proksi-servera/shlyuza na etot zapros DOLZHEN
imet' tu zhe samuyu major versiyu, chto i zapros.
Obratite vnimanie: Preobrazovanie versij HTTP mozhet vklyuchat'
modifikaciyu polej zagolovka, trebuemyh ili zapreshchennyh v etih
versiyah.
3.2 Universal'nye Identifikatory Resursov (URI).
URI izvestny pod mnogimi imenami: WWW adresa, Universal'nye
Identifikatory Dokumentov, Universal'nye Identifikatory Resursov
(URI), i, v zaklyuchenie, kak kombinaciya Edinoobraznyh Identifikatorov
Resursa (Uniform Resource Locators, URL) i Edinoobraznyh Imen
Resursa (Uniform Resource Names, URN). HTTP opredelyaet URL prosto
kak stroku opredelennogo formata, kotoraya identificiruet - cherez
imya, raspolozhenie, ili lyubuyu druguyu harakteristiku - resurs.
3.2.1 Obshchij sintaksis.
URI v HTTP mogut predstavlyat'sya v absolyutnoj (absolute) forme ili
otnositel'no nekotoroj izvestnoj osnovy URI (relative), v
zavisimosti ot konteksta ih ispol'zovaniya. |ti dve formy
razlichayutsya tem, chto absolyutnye URI vsegda nachinayutsya s imeni
shemy s dvoetochiem.
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <lyuboj OCTET za isklyucheniem ALPHA, DIGIT,
reserved, extra, safe, i unsafe>
Polnuyu informaciyu otnositel'no sintaksisa i semantiki URL smotrite
RFC 1738 [4] I RFC 1808 [11]. Vysheukazannaya normal'naya zapis'
Bekusa-Naura vklyuchaet nacional'nye simvoly, nedozvolennye v
dopustimyh URL (eto opredeleno v RFC 1738), tak kak HTTP servery
pozvolyayut ispol'zovat' dlya predstavleniya chasti rel_path adresov
nabor nezarezervirovannyh simvolov, i, sledovatel'no, HTTP
proksi-servera mogut poluchat' zaprosy URI, ne sootvetstvuyushchie
RFC 1738.
Protokol HTTP ne nakladyvaet a priori nikakih ogranichenij na dliny
URI. Servery DOLZHNY byt' sposobny obrabotat' URI lyubogo resursa,
kotoryj oni obsluzhivayut, i im SLEDUET byt' v sostoyanii obrabatyvat'
URI neogranichennoj dliny, esli oni obsluzhivayut formy, osnovannye
na metode GET, kotorye mogut generirovat' takoj URI. Serveru
SLEDUET vozvrashchat' kod sostoyaniya 414 (URI zaprosa slishkom dlinnyj,
Request-URI Too Long), esli URI bol'she, chem server mozhet obrabotat'
(smotrite razdel 10.4.15).
Obratite vnimanie: Servery dolzhny byt' ostorozhny s URI, kotorye
imeyut dlinu bolee 255 bajtov, potomu chto nekotorye starye
klienty ili proksi-servera ne mogut pravil'no podderzhivat'
eti dliny.
"Http" shema ispol'zuetsya dlya dostupa k setevym resursam pri pomoshchi
protokola HTTP. |tot razdel opredelyaet shemo-opredelennyj sintaksis
i semantiku dlya HTTP URL.
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <dopustimoe domennoe imya mashiny
ili IP adres (v tochechno-desyatichnoj forme),
kak opredeleno v razdele 2.1 RFC 1123>
port = *DIGIT
Esli port pust ili ne zadan - ispol'zuetsya port 80. |to oznachaet,
chto identificirovannyj resurs razmeshchen v servere, ozhidayushchem TCP
soedinenij na specificirovannom porte port, komp'yutera host, i
zaprashivaemyj URI resursa - abs_path. Ispol'zovaniya IP adresov v
URL SLEDUET izbegat', kogda eto vozmozhno (smotrite RFC 1900 [24]).
Esli abs_path ne predstavlen v URL, on DOLZHEN rassmatrivat'sya kak
"/" pri vychislenii zaprashivaemogo URI (Request-URI) resursa
(razdel 5.1.2).
Pri sravnenii dvuh URI, chtoby reshit' sootvetstvuyut li oni drug
drugu ili net, klientu SLEDUET ispol'zovat' chuvstvitel'noe k
registru pooktetnoe (octet-by-octet) sravnenie etih URI, so
sleduyushchimi isklyucheniyami:
o Port, kotoryj pust ili ne ukazan, ekvivalenten zadannomu po
umolchaniyu portu dlya etogo URI;
o Sravnenie imen hostov DOLZHNO proizvodit'sya bez ucheta registra;
o Sravnenie imen shem DOLZHNO proizvodit'sya bez ucheta registra;
o Pustoj abs_path ekvivalenten "/".
Simvoly, otlichnye ot teh, chto nahodyatsya v "zarezervirovannyh"
("reserved") i "opasnyh" ("unsafe") naborah (sm. razdel 3.2)
ekvivalentny ih kodirovaniyu kak ""%" HEX HEX ".
Naprimer sleduyushchie tri URI ekvivalentny:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 Formaty daty/vremeni.
HTTP prilozheniya istoricheski dopuskali tri razlichnyh formata dlya
predstavleniya daty/vremeni:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, dopolnennyj v RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, perepisannyj kak RFC 1036
Sun Nov 6 08:49:37 1994 ; format asctime() ANSI C
Pervyj format vybran v kachestve standarta Interneta i predstavlyaet
podmnozhestvo fiksirovannoj dliny, kak opredeleno v RFC 1123
(modificirovannom RFC 822). Vtoroj format nahoditsya v obshchem
pol'zovanii, no osnovan na ustarevshem i poteryavshem status standarta
RFC 850 [12], opisyvayushchem formaty dat, on obladaet tem nedostatkom,
chto god ukazyvaetsya ne v chetyrehrazryadnoj notacii. Klienty i
servery HTTP/1.1, kotorye analiziruyut znachenie daty, DOLZHNY
ponimat' vse tri formata (dlya sovmestimosti s HTTP/1.0), no
generirovat' dlya predstavleniya znachenij dat v polyah zagolovka HTTP
DOLZHNY tol'ko format RFC 1123 .
Obratite vnimanie: Pooshchryaetsya praktika, pri kotoroj poluchateli
znachenij dat zdravo vosprinimayut znacheniya dat, kotorye, vozmozhno,
poslany ne HTTP prilozheniyami, chto imeet mesto pri zagruzke ili
registracii soobshchenij cherez proksi-servera/shlyuzy k SMTP ili NNTP.
Vse bez isklyuchenij formaty HTTP daty/vremeni DOLZHNY byt'
predstavleny v Greenwich Mean Time (GMT). V pervyh dvuh formatah
dannyj fakt ukazyvaetsya vklyucheniem trehsimvol'nogo sokrashcheniya "GMT"
v kachestve chasovogo poyasa. V asctime() formate eto DOLZHNO
podrazumevat'sya pri chtenii.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; den' mesyac god (naprimer 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; den'-mesyac-god (naprmer 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; mesyac den' (naprimer, Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Obratite vnimanie: |ti trebovaniya - eto trebovaniya k dlya
formatam daty/vremeni, kotorye primenyayutsya vnutri potoka
protokola HTTP. Klientam i serveram ne trebuetsya ispol'zovat'
eti formaty dlya predstavleniya pol'zovatelyu, registracii
zaprosov i t.d.
3.3.2 Raznost' sekund (delta seconds).
Nekotorye polya HTTP zagolovka pozvolyayut ukazyvat' znacheniya vremeni
v vide celogo chisla sekund, predstavlennogo v desyatichnoj forme,
kotorye dolzhny projti s togo momenta, kak soobshchenie bylo polucheno.
delta-seconds = 1*DIGIT
3.4 Kodovye tablicy (character sets).
HTTP ispol'zuet to zhe samoe opredelenie termina "kodovaya tablica",
kotoroe opisano dlya MIME:
Termin "kodovaya tablica" ispol'zuetsya v dannom dokumente, chtoby
soslat'sya na metod, ispol'zuyushchij odnu ili neskol'ko tablic dlya
preobrazovaniya posledovatel'nosti oktetov v posledovatel'nost'
simvolov. Stoit otmetit', chto odnoznachnoe preobrazovanie v
obratnom napravlenii ne trebuetsya, i chto ne vse simvoly mogut
byt' dostupny v dannoj kodovoj tablice, i chto kodovaya tablica
mozhet obespechivat' bolee chem odnu posledovatel'nost' oktetov dlya
predstavleniya specificheskih simvolov. |to opredelenie dopuskaet
razlichnye vidy kodirovaniya simvolov, ot prostyh odnotablichnyh
otobrazhenij tipa US-ASCII do slozhnyh metodov, pereklyuchayushchih
tablicy, napodobie teh, kotorye ispol'zuyut metodiki ISO 2022.
Odnako opredelenie, svyazannoe s imenem kodovoj tablicy MIME
DOLZHNO polnost'yu opredelyat' otobrazhenie, kotoroe preobrazuet
oktety v simvoly. V chastnosti ispol'zovanie vneshnej informacii
profilirovaniya dlya opredeleniya tochnogo otobrazheniya ne
razreshaetsya.
Obratite vnimanie: |to ispol'zovanie termina "kodovaya tablica"
obychno upominaetsya kak "kodirovanie simvolov". Odnako, s teh por
kak HTTP i MIME sovmestno ispol'zuyut odinnakovuyu zapis', vazhno,
chtoby sovpadala takzhe i terminologiya.
Kodovye tablicy HTTP identificiruyutsya leksemami, ne chuvstvitel'nymi
k registru. Polnyj nabor leksem opredelen reestrom kodovyh tablic
IANA [19].
charset = token
Hotya HTTP pozvolyaet ispol'zovat' v kachestve znacheniya charset
proizvol'nuyu leksemu, lyubaya leksema, kotoraya imeet predopredelennoe
znachenie v reestre kodovyh tablic IANA, DOLZHNA predstavlyat' nabor
simvolov, opredelennyj v dannom reestre. Prilozheniyam SLEDUET
ogranichit' ispol'zovanie simvol'nyh naborov temi, kotorye
opredeleny v reestre IANA.
3.5 Kodirovanie soderzhimogo (content codings).
Znachenie kodirovaniya soderzhimogo ukazyvaet kakoe preobrazovanie
kodirovaniya bylo ili budet primeneno k ob容ktu. Kodirovanie
soderzhimogo ispol'zuetsya prezhde vsego dlya szhatiya ili drugogo
poleznogo preobrazovaniya k dokumentu bez poteri identifikacii
osnovnogo media tipa i informacii. CHasto, ob容kt sohranyaetsya v
kodirovannoj forme, zatem peredaetsya, a potom dekodiruetsya
poluchatelem.
content-coding = token
Vse znacheniya kodirovaniya soderzhimogo (content-coding) ne
chuvstvitel'ny k registru. HTTP/1.1 ispol'zuet znacheniya kodirovaniya
soderzhimogo (content-coding) v polyah zagolovka Accept-Encoding
(razdel 14.3) i Content-Encoding (razdel 14.12). Hotya znachenie
opisyvaet kodirovanie soderzhimogo, no, chto bolee vazhno - ono
ukazyvaet, kakoj mehanizm dekodirovaniya potrebuetsya dlya obratnogo
processa.
Internet Assigned Numbers Authority (IANA) dejstvuet kak reestr
dlya znachenij leksem kodirovaniya soderzhimogo (content-coding).
Pervonachal'no reestr soderzhal sleduyushchie leksemy:
gzip
Format kodirovaniya, proizvodyashchij szhatie fajla programmoj "gzip"
(GNU zip), kak opisano v RFC 1952 [25]. |to format Lempel-Ziv
kodirovaniya (LZ77) s 32 razryadnym CRC.
compress
Format kodirovaniya, proizvodimyj obshchej programmoj "compress" dlya
szhatiya UNIX fajlov. |to format adaptivnogo Lempel-Ziv-Welch
kodirovaniya (LZW).
Obratite vnimanie: Ispol'zovat' nazvaniya programm dlya
identifikacii formatov kodirovaniya ne zhelatel'no i dolzhno byt'
ne ponyatno budushchim kodirovaniyam. Ih ispol'zovanie zdes'
ob座asnyaetsya istoricheskoj praktikoj, no tak delat' ne nuzhno. Dlya
sovmestimosti s predydushchimi realizaciyami HTTP, prilozheniya dolzhny
rassmatrivat' "x-gzip" i "x-compress" kak ekvivalenty "gzip" i
"compress" sootvetstvenno.
deflate
Format zlib, opredelennyj v RFC 1950 [31], v kombinacii s
mehanizmom szhatiya "deflate", opisannym v RFC 1951 [29].
Novaya leksema znacheniya kodirovaniya soderzhimogo (content-coding)
dolzhna byt' zaregistrirovana; chtoby obespechit' vzaimodejstvie mezhdu
klientami i serverami, specifikaciya algoritma kodirovaniya
soderzhimogo, neobhodimogo dlya opredeleniya novogo znacheniya, dolzhna
byt' otkryto opublikovana i adekvatna dlya nezavisimoj realizacii,
a takzhe sootvetstvovat' celi kodirovaniya soderzhimogo opredelennogo
v etom razdele.
3.6 Kodirovanie peredachi (Transfer Codings).
Znacheniya kodirovaniya peredachi ispol'zuyutsya dlya ukazaniya
preobrazovaniya kodirovaniya, kotoroe bylo ili dolzhno byt' primeneno
k telu ob容kta (entity-body) v celyah garantirovaniya "bezopasnoj
peredachi" po seti. Ono otlichaetsya ot kodirovaniya soderzhimogo tem,
chto kodirovanie peredachi - eto svojstvo soobshcheniya, a ne
pervonachal'nogo ob容kta.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
Vse znacheniya kodirovaniya peredachi (transfer-coding) ne
chuvstvitel'ny k registru. HTTP/1.1 ispol'zuet znacheniya kodirovaniya
peredachi (transfer-coding) v pole zagolovka Transfer-Encoding
(razdel 14.40).
Kodirovaniya peredachi - eto analogi znachenij
Content-Transfer-Encoding MIME, kotorye byli razrabotany dlya
obespecheniya bezopasnoj peredachi dvoichnyh dannyh pri ispol'zovanii
7-bitnogo obsluzhivaniya peredachi. Odnako bezopasnyj transport
imeet drugoe prednaznachenie dlya chisto 8-bitnogo protokola peredachi.
V HTTP edinstvenaya opasnaya harakteristika tela soobshcheniya vyzvana
slozhnost'yu opredeleniya tochnoj dliny tela soobshcheniya (razdel 7.2.2),
ili zhelaniem shifrovat' dannye pri pol'zovanii obshchedostupnym
transportom.
Kodirovanie po kuskam (chunked encoding) izmenyaet telo soobshcheniya
dlya peredachi ego posledovatel'nost'yu kuskov, kazhdyj iz kotoryh
imeet sobstvennyj indikator razmera, soprovozhdaemym opcional'nym
zavershitelem, soderzhashchim polya zagolovka ob容kta. |to pozvolyaet
dinamicheski sozdavaemomu soderzhimomu peredavat'sya vmeste s
informaciej, neobhodimoj poluchatelyu dlya proverki polnoty polucheniya
soobshcheniya.
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero = <HEX za isklyucheniem "0">
chunk-size = hex-no-zero *HEX
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
footer = *entity-header
Kodirovanie po kuskam (chunked encoding) okanchivaetsya kuskom
nulevogo razmera, sleduyushchim za zavershitelem, okanchivayushchimsya pustoj
strokoj. Cel' zavershitelya sostoit v effektivnom metode obespecheniya
informacii ob ob容kte, kotoryj sgenerirovan dinamicheski; prilozheniya
NE DOLZHNY posylat' v zavershitele polya zagolovka, kotorye yavno ne
prednaznacheny dlya ispol'zovaniya v zavershitele, takie kak
Content-MD5 ili budushchie rasshireniya HTTP dlya cifrovyh podpisej i
drugih vozmozhnostej.
Primernyj process dekodirovaniya Chunked-Body predstavlen v
prilozhenii 19.4.6.
Vse HTTP/1.1 prilozheniya DOLZHNY byt' v sostoyanii poluchat' i
dekodirovat' kodirovanie peredachi "po kuskam" ("chunked" transfer
coding), i DOLZHNY ignorirovat' rasshireniya kodirovaniya peredachi,
kotorye oni ne ponimayut. Serveru, kotoryj poluchil telo ob容kta so
znacheniem kodirovaniya peredachi, kotoroe on ne ponimaet, SLEDUET
vozvratit' otvet s kodom 501 (Ne realizovano, Not Implemented) i
razorvat' soedinenie. Server NE DOLZHEN posylat' polya kodirovaniya
peredachi (transfer-coding) HTTP/1.0 klientam.
3.7 Media tipy (Media Types).
HTTP ispol'zuet Media Tipy Interneta (Internet Media Types) v polyah
zagolovka Content-Type (razdel 14.18) i Accept (razdel 14.1) dlya
obespecheniya otkrytoj i rasshiryaemoj tipizacii dannyh i obsuzhdeniya
tipov.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Parametry mogut sledovat' za type/subtype v forme par
atribut/znachenie (attribute/value).
parameter = attribute "=" value
attribute = token
value = token | quoted-string
Tip, podtip, i imena atributov i parametrov ne chuvstvitel'ny k
registru. Znacheniya parametrov mogut byt' chuvstvitel'nymi k registru,
no mogut byt' i ne chuvstvitel'ny, v zavisimosti ot semantiki imeni
parametra. Linejnyj probel (LWS) NE DOLZHEN ispol'zovat'sya mezhdu
tipom i podtipom, mezhdu atributom i znacheniem. Agenty pol'zovatelej,
raspoznayushchie media tipy, DOLZHNY obrabatyvat' (ili podgotavlivat'
dlya obrabotki lyubymi vneshnimi prilozheniyami) parametry dlya teh tipov
MIME, kotorye opisany, i soobshchat' pol'zovatelyu o obnaruzhennyh
problemah.
Obratite vnimanie: Nekotorye starye HTTP prilozheniya ne raspoznayut
parametry media tipov. Pri posylke dannyh k takim HTTP prilozheniyam
realizacii dolzhny ispol'zovat' parametry media tipov tol'ko kogda
eto trebuetsya po opredeleniyu tipa/podtipa.
Znacheniya media-tipov registriruyutsya Internet Assigned Number
Authority (IANA). Process registracii media tipa opredelen v RFC
2048 [17]. Ispol'zovanie ne zaregistrirovannyh media tipov vvodit
v zabluzhdenie.
3.7.1 Kanonizaciya i predopredelennye znacheniya tipa text.
Media tipy Interneta zaregistrirovany v kanonicheskoj forme. Voobshche,
telo ob容kta, peredavaemoe HTTP soobshcheniem, DOLZHNO byt'
predstavleno v sootvetstvuyushchej kanonicheskioj forme do peredachi;
isklyuchenie sostavlyayut tipy "text", opredelyaemye v sleduyushchem abzace.
V kanonicheskoj forme media podtipy tipa "text" ispol'zuyut CRLF v
kachestve metki konca stroki. HTTP oslablyaet eto trebovanie i
pozvolyaet peredavat' tekst razmechennyj takim obrazom, chto edenichnye
CR ili LF mogut byt' metkami konca stroki, pravda eto pravilo
dolzhno byt' vypolneno dlya vsego tela ob容kta (entity-body). HTTP
prilozheniya DOLZHNY vosprinimat' CRLF, prosto CR, i prosto LF kak
predstavlenie konca stroki v tekstovyh tipah, peredannyh po HTTP.
Krome togo, esli tekst predstavlyaetsya v kodovoj tablice, kotoraya
ne ispol'zuet oktety 13 i 10 dlya CR i LF sootvetstvenno, chto imeet
mesto v nekotoryh mnogobajtovyh kodovyh tablicah, to HTTP pozvolyaet
ispol'zovat' lyubye posledovatel'nosti oktetov, opredelennye etim
naborom simvolov dlya predstavleniya ekvivalentov CR i LF v kachestve
koda konca stroki. |ta gibkost' v otnoshenii koncov strok primenima
tol'ko k tekstovym tipam v tele ob容kta; prosto CR ili prosto LF NE
DOLZHNY zamenyat' CRLF vnutri lyuboj upravlyayushchej struktury HTTP (tipa
polya zagolovka i razdelitelej tipa multipart).
Esli telo ob容kta kodiruetsya pri pomoshchi Content-Encoding, to
osnovnye dannye DOLZHNY byt' v opredelennoj vyshe forme do
kodirovaniya.
Parametr "charset" ispol'zuetsya s nekotorymi media tipami dlya
ukazaniya kodovoj tablicy (razdel 3.4), ispol'zuemoj dlya
predstavleniya dannyh. Esli parametr "charset" ne ukazan
otpravitelem, to pri poluchenii po HTTP media podtipy tipa "text"
imeyut znachenie "charset", po umolchaniyu ravnoe "ISO-8859-1". Dannye
v kodovyh tablicah ili ih podmnozhestvah, otlichnyh ot "ISO-8859-1"
DOLZHNY byt' pomecheny sootvetstvuyushchim znacheniem "charset".
Nekotoroe programmnoe obespechenie HTTP/1.0 interpretirovalo
zagolovok Content-Type bez parametra "charset" nepravil'no, kak
oznachayushchee "dolzhen predpolozhit' poluchatel'". Otpraviteli, zhelayushchie
predusmotret' takoe povedenie MOGUT vklyuchat' parametr "charset"
dazhe kogda charset raven ISO-8859-1 i DOLZHNY sdelat' eto, esli
izvestno, chto eto ne zaputaet poluchatelya.
K sozhaleniyu, nekotorye starye HTTP/1.0 klienty ne rabotali pravil'no
s opredeleniem parametra "charset". HTTP/1.1 poluchateli DOLZHNY
otdavat' prioritet metke "charset", postavlennoj otpravitelem; i te
agenty pol'zovatelej, kotorye imeyut vozmozhnost' "predpolozhit'"
charset DOLZHNY pri pervonachal'nom otobrazhenii dokumenta ispol'zovat'
charset iz polya content-type, esli oni podderzhivayut takoj charset,
a zatem ispol'zovat' sobstvennye ustanovki.
MIME predusmatrivaet ryad tipov "multipart" - formiruyushchih paket iz
odnogo ili neskol'kih ob容ktov vnutri tela odnogo soobshcheniya. Vse
tipy mulptipart ispol'zuyut obshchij sintaksis, opredelenyj v MIME [7],
i DOLZHNY soderzhat' razdelitel'nyj parametr chast'yu znacheniya media
tipa. Telo soobshcheniya - samostoyatel'nyj element protokola i,
sledovatel'no, DOLZHNO ispol'zovat' tol'ko SRLF dlya predstavleniya
koncov strok mezhdu chastyami tela (body-parts). V otlichie ot MIME,
okonchanie lyubogo multipart soobshcheniya DOLZHNO byt' pustym; HTTP
prilozheniya NE DOLZHNY peredavat' okonchanie (dazhe esli pervonachal'nyj
multipart soderzhit zaklyuchenie).
V HTTP chasti tela (body-parts) tipa multipart MOGUT soderzhat' polya
zagolovka, kotorye yavlyayutsya znachashchimi v primnenii k etoj chasti.
Pole zagolovka Content-Location (razdel 14.15) SLEDUET vklyuchat' v
chast' tela (body-part) kazhdogo vklyuchennogo ob容kta, kotoryj mozhet
byt' identificirovan URL.
Voobshche govorya, HTTP agentu pol'zovatelya SLEDUET sledovat' takomu zhe
ili podobnomu povedeniyu, kotoromu sledoval by MIME agent
pol'zovatelya posle polucheniya tipa multipart. Esli prilozhenie
poluchaet nezaregistrirovannyj podtip multipart, ono DOLZHNO
obrabatyvat' ego kak podtip "multipart/mixed".
Obratite vnimanie: tip "multipart/form-data" byl special'no
opredelen dlya peredachi dannyh formy, podhodyashchih dlya obrabotki
metodom zaprosa POST, chto opisano v RFC 1867 [15].
3.8 Leksemy programm (Product Tokens).
Leksemy programm ispol'zuyutsya, chtoby obespechit' kommunikacionnym
prilozheniyam vozmozhnost' identificirovat' sebya nazvaniem i versiej
programmnogo obespecheniya. Bol'shinstvo polej, ispol'zuyushchih leksemy
programm takzhe dopuskaet perechislenie podprogramm, kotorye formiruyut
znachitel'nuyu chast' prilozheniya, i kotorye perechislyayutsya cherez probel.
V sootvetstvii s soglasheniem, podprogrammy perechislyayutsya v poryadke
ih znacheniya dlya identifikacii prilozheniya.
product = token ["/" product-version]
product-version = token
Primery:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Leksemy programm dolzhny byt' korotkimi i po suti - ispol'zovanie ih
dlya reklamy ili drugoj nesushchestvennoj informacii odnoznachno
zapreshcheno. Hotya v lekseme product-version mozhet vstrechat'sya lyuboj
simvol, vse zhe ee sleduet ispol'zovat' tol'ko dlya identifikatora
versii (to est', posledovatel'nym versiyam odnoj i toj zhe programmy
SLEDUET imet' otlichiya tol'ko v chasti product-version leksemy
product.
3.9 Kachestvennye znacheniya (Quality Values).
Obsuzhdenie soderzhimogo HTTP (razdel 12) ispol'zuet korotkie chisla "s
plavayushchej tochkoj" dlya ukazaniya otnositel'noj vazhnosti ("vesa")
razlichnyh ogovorennyh parametrov. Ves - eto normalizovanoe
veshchestvennoe chislo v diapazone ot 0 do 1, gde 0 - minimal'noe, a
1 - maksimal'noe znachenie. HTTP/1.1 prilozheniya NE DOLZHNY
generirovat' bolee treh cifr posle desyatichnoj tochki.
Pol'zovatel'skim konfiguraciyam etih znachenij SLEDUET takzhe
ogranichivat'sya etim rezhimom.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
"Kachestvennye znacheniya" - ne korrektnoe nazvanie, tak kak eti
znacheniya prosto predstavlyayut otnoshenie snizheniya proizvoditel'nosti
k zhelatel'nomu kachestvu.
3.10 Metki yazykov (Language Tags).
Metka yazyka identificiruet estestvennyj yazyk: razgovornyj,
pis'mennyj, ili drugoj ispol'zuemyj lyud'mi dlya obmena informacmej
s drugimi lyud'mi. Mashinnye yazyki yavlyayutsya isklyucheniem. HTTP
ispol'zuet metki yazyka vnutri polej Accept-Language i
Content-Language.
Sintaksis i zapis' HTTP metok yazyka takie zhe, kak opredelyaemye
RFC 1766 [1]. V rezyume, metka yazyka sostoit iz odnoj ili neskol'kih
chastej: metka pervichnogo yazyka i, vozmozhno pustoj, ryad podchinennyh
metok:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Vnutri metki ne dopustim probel i vse metki ne chuvstvitel'ny k
registru. Prostranstvo imen metok yazyka upravlyaetsya IANA. Naprimer
metki soderzhat:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Lyubaya dvuhsimvol'naya pervichnaya metka yavlyaetsya metkoj abbreveatury
yazyka ISO 639, a lyubaya dvuhsimvol'naya podchinennaya metka yavlyaetsya
metkoj koda strany ISO 3166. (Poslednie tri metki iz
vysheperechislennyh - ne zaregistrirovannye metki; vse, krome
poslednej - primery metok, kotorye mogli by byt' zaregistrirovany
v budushchem.)
3.11 Metki ob容ktov (Entity Tags).
Metki ob容ktov ispol'zuyutsya dlya sravneniya dvuh ili bolee ob容ktov
ot odnogo i togo zhe zaproshennogo resursa. HTTP/1.1 ispol'zuet metki
ob容kta v polyah zagolovka ETag (razdel 14.20), If-Match (razdel
14.25), If-None-Match (razdel 14.26), i If-Range (razdel 14.27).
Opredelenie togo, kak oni ispol'zuyutsya i sravnivayutsya v kachestve
metok proverki kesha nahoditsya v razdele 13.3.3. Metka ob容kta
sostoit iz neprozrachnoj citiruemoj stroki (opaque quoted string),
vozmozhno predvarennoj indikatorom slabosti (weakness indicator).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
"Sil'naya metka ob容kta" ("strong entity tag") mozhet byt' razdelena
dvumya ob容ktami resursa, tol'ko esli oni pooktetno ekvivalentny.
"Slabaya metka ob容kta" ("weak entity tag"), oboznachyaemaya prefiksom
"W/", mozhet byt' razdelena dvumya ob容ktami resursa tol'ko esli
ob容kty ekvivalentny i mogli by zamenyat' drug druga bez
znachitel'nogo izmeneniya v semantike. Slabaya metka ob容kta mozhet
ispol'zovat'sya tol'ko dlya slabogo sravneniya.
Metka ob容kta DOLZHNA byt' unikal'na sredi vseh versij vseh
ob容ktov, svyazannyh s konkretnym resursom. Dannoe znachenie metki
ob容kta mozhet ispol'zovat'sya dlya ob容ktov, poluchennyh zaprosami
razlichnyh URI bez predpolozheniya ekvivalentnosti etih ob容ktov.
3.12 Edenicy izmereniya diapazonov (Range Units).
HTTP/1.1 pozvolyaet klientu zaprashivat' tol'ko chast' ob容kta.
HTTP/1.1 ispol'zuet edenicy izmereniya diapazonov v polyah zagolovka
Range (razdel 14.36) i Content-Range (razdel 14.17). Ob容kt mozhet
byt' razbit na chasti sootvetstvenno razlichnym strukturnym modulyam.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
Edinstvenaya edenica izmereniya diapazonov, opredelennaya v HTTP/1.1
- eto "bytes". Realizacii HTTP/1.1 mogut ignorirovat' diapazony,
opredelennye s ispol'zovaniem drugih edenic izmereniya. HTTP/1.1
byl razrabotan, chtoby dopuskat' realizacii prilozhenij, kotorye ne
zavisyat ot znaniya diapazonov.
4 HTTP soobshchenie (HTTP Message).
HTTP soobshcheniya delyatsya na zaprosy klienta serveru i otvety servera
klientu.
HTTP-message = Request | Response ; soobshcheniya HTTP/1.1
Soobshcheniya zaprosa (razdel 5) i otveta (razdel 6) ispol'zuyut
obobshchennyj format soobshcheniya RFC 822 [9] dlya peresylki ob容ktov
(poleznoj nagruzki soobshcheniya). Oba tipa soobshchenij vyglyadyat
sleduyushchim obrazom: snachala idet nachal'naya stroka (start-line),
zatem odin ili neskol'ko polej zagolovka (nazyvaemyh takzhe prosto
"zagolovki"), zatem pustaya stroka (to est' stroka, ravnaya CRLF),
ukazyvayushchaya konec polej zagolovka, a zatem, vozmozhno, telo
soobshcheniya.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
V interesah oshibkoustojchivosti, serveram SLEDUET ignorirovat'
vse pustye stroki, poluchennye pered strokoj zaprosa
(Request-Line). Drugimi slovami, esli server chitaet potok
protokola i v samom nachale soobshcheniya poluchaet CRLF, to emu sleduet
etot CRLF ignorirovat'.
Obratite vnimanie: nekotorye oshibochnye realizacii HTTP/1.0
klientov generiruyut dopolnitel'nye CRLF posle zaprosa POST.
Stoit vnov' povtorit', chto eto yavno zapreshcheno normal'noj zapis'yu
Bekusa-Naura. HTTP/1.1 klient ne dolzhen dobavlyat' dopolnitel'nye
CRLF pered zaprosom i posle nego.
4.2 Zagolovki soobshchenij.
Polya zagolovkov HTTP, kotorye vklyuchayut polya obshchih zagolovkov
(general-header) (razdel 4.5), zagolovkov zaprosa (request-header)
(razdel 5.3), zagolovkov otveta (response-header) (razdel 6.2), i
zagolovkov ob容kta (entity-header) (razdel 7.1), imeyut takoj zhe
obobshchennyj format, chto opisan v razdele 3.1 RFC 822 [9]. Kazhdoe
pole zagolovka sostoit iz imeni, dvoetochiya (":") i znacheniya polya.
Imena polej ne chuvstvitel'ny k registru. Znacheniyu polya mozhet
predshestvovat' lyuboe chislo LWS, hotya predpochtitelen odinochnyj SP.
Polya zagolovka mogut zanimat' neskol'ko strok. Pri etom kazhdaya
sleduyushchaya stroka nachinaetsya po krajnej mere odnim SP ili HT.
Prilozheniyam SLEDUET priderzhivat'sya "obshchej formy" ("common form")
pri generacii HTTP konstrukcij, tak kak mogut sushchestvovat'
realizacii, kotorye ne v sostoyanii prinimat' chto-libo krome obshchih
form.
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <oktety, sostavlyayushchie znachenie polya i
sostoyashchie ili iz *TEXT ili iz kombinacij
leksem, tspecials, i quoted-string>
Poryadok, v kotorom polucheny polya zagolovka s razlichnymi imenami
ne imeet znacheniya. Odnako "horoshaya praktika" zaklyuchaetsya v tom,
chto snachala posylayutsya polya obshchih zagolovkov, zatem polya
zagolovkov zaprosa ili zagolovkov otveta, i, nakonec, polya
zagolovkov ob容kta.
Neskol'ko polej zagolovka s odinnakovymi imenami mogut
prisutstvovat' v soobshchenii togda, i tol'ko togda, kogda vse
znacheniya polej, vhodyashchih v zagolovok, opredelyayut razdelennyj
zapyatymi spisok [to est' #(value)]. DOLZHNO byt' vozmozhno
ob容dinit' neskol'ko takih polej zagolovka v odnu paru "imya polya:
znachenie polya" (ne izmenenyaya etim semantiku soobshcheniya) prisoedinyaya
kazhdoe posleduyushchee znachenie polya k pervomu cherez zapyatye. Poryadok,
v kotorom polucheny polya s odinakovymi imenami, imeet znachenie
dlya interpretacii ob容dinennogo znacheniya polya, i, sledovatel'no,
proksi-server NE DOLZHEN izmenyat' poryadok znachenij etogo polya pri
peresylke.
Telo HTTP soobshcheniya (message-body), esli ono prisutstvuet,
ispol'zuetsya dlya peredachi tela ob容kta, svyazannogo s zaprosom ili
otvetom. Telo soobshcheniya (message-body) otlichaetsya ot tela ob容kta
(entity-body) tol'ko v tom sluchae, kogda primenyaetsya kodirovanie
peredachi, chto ukazyvaetsya polem zagolovka Transfer-Encoding
(razdel 14.40).
message-body = entity-body
| <entity-body zakodirovanno soglasno
Transfer-Encoding>
Pole Transfer-Encoding DOLZHNO ispol'zovat'sya dlya ukazaniya lyubogo
kodirovaniya peredachi, primenennogo prilozheniem v celyah
garantirovaniya bezopasnoj i pravil'noj peredachi soobshcheniya. Pole
Transfer-Encoding - eto svojstvo soobshcheniya, a ne ob容kta, i, takim
obrazom, mozhet byt' dobavleno ili udaleno lyubym prilozheniem v
cepochke zaprosov/otvetov.
Pravila, ustanavlivayushchie dopustimost' tela soobshcheniya v soobshchenii,
otlichny dlya zaprosov i otvetov.
Prisutstvie tela soobshcheniya v zaprose otmechaetsya dobavleniem k
zagolovkam zaprosa polya zagolovka Content-Length ili
Transfer-Encoding. Telo soobshcheniya (message-body) MOZHET byt'
dobavleno v zapros tol'ko kogda metod zaprosa dopuskaet telo
ob容kta (entity-body) (razdel 5.1.1).
Vklyuchaetsya ili ne vklyuchaetsya telo soobshcheniya (message-body) v
soobshchenie otveta zavisit kak ot metoda zaprosa, tak i ot koda
sostoyaniya otveta (razdel 6.1.1). Vse otvety na zapros s metodom
HEAD NE DOLZHNY vklyuchat' telo soobshcheniya (message-body), dazhe esli
prisutstvuyut polya zagolovka ob容kta (entity-header), zastavlyayushchie
poverit' v prisutstvie ob容kta. Nikakie otvety s kodami sostoyaniya 1xx
(Informacionnye), 204 (Net soderzhimogo, No Content), i 304 (Ne
modificirovan, Not Modified) NE DOLZHNY soderzhat' tela soobshcheniya
(message-body). Vse drugie otvety soderzhat telo soobshcheniya, dazhe
esli ono imeet nulevuyu dlinu.
Kogda telo soobshcheniya (message-body) prisutstvuet v soobshchenii,
dlina etogo tela opredelyaetsya odnim iz sleduyushchih metodov (v
poryadke starshinstva):
1. Lyuboe soobshchenie otveta, kotoroe NE DOLZHNO vklyuchat' telo
soobshcheniya (message-body) (naprimer otvety s kodami sostoyaniya
1xx, 204, 304 i vse otvety na zapros HEAD) vsegda zavershaetsya
pustoj strokoj posle polej zagolovka, nezavisimo ot polej
zagolovka ob容kta (entity-header fields), predstavlennyh v
soobshchenii.
2. Esli pole zagolovka Transfer-Encoding (razdel 14.40)
prisutstvuet i ukazyvaet na primenenie kodirovaniya peredachi
"chunked", to dlina opredelyaetsya kodirovaniem po kuskam
(chunked encoding) (razdel 3.6).
3. Esli pole zagolovka Content-Length (razdel 14.14) prisutstvuet,
to ego znachenie predstavlyaet dlinu tela soobshcheniya
(message-body) v bajtah.
4. Esli soobshchenie ispol'zuet media tip "multipart/byteranges",
kotoryj samorazgranichen, to on i opredelyaet dlinu. |tot media
tip NE DOLZHEN ispol'zovat'sya, esli otpravitel' ne znaet, chto
poluchatel' mozhet ego obrabotat'; prisutstvie v zaprose
zagolovka Range s neskol'kimi specifikatorami diapazonov bajtov
(byte-range) podrazumevaet, chto klient mozhet analizirovat'
multipart/byteranges otvety.
5. Dlina opredelyaetsya zakrytiem soedineniya serverom. (Zakrytie
soedineniya ne mozhet ispol'zovat'sya dlya ukazaniya konca tela
zaprosa, tak kak v etom sluchae u servera ne ostaetsya nikakoj
vozmozhnosti poslat' obratno otvet).
Dlya sovmestimosti s HTTP/1.0 prilozheniyami HTTP/1.1 zaprosy,
soderzhashchie telo soobshcheniya (message-body) DOLZHNY vklyuchat'
dopustimoe pole zagolovka Content-Length, esli ne izvestno, chto
server yavlyaetsya HTTP/1.1 sovmestimym. Esli zapros soderzhit telo
soobshcheniya (message-body), i Content-Length ne ukazano, serveru
SLEDUET poslat' otvet s kodom sostoyaniya 400 (Isporchennyj Zapros,
Bad Request), esli on ne mozhet opredelit' dlinu soobshcheniya, ili
s kodom sostoyaniya 411 (Trebuetsya dlina, Length Required), esli on
nastaivaet na poluchenii Content-Length.
Vse HTTP/1.1 prilozheniya, kotorye poluchayut ob容kty, DOLZHNY ponimat'
kodirovanie peredachi tipa "chunked" (razdel 3.6), takim obrazom
razreshaetsya ispol'zovanie dannogo mehanizma dlya takih soobshchenij,
dlina kotoryh ne mozhet byt' opredelena zaranee.
Soobshcheniya NE DOLZHNY odnovremenno vklyuchat' i pole zagolovka
Content-Length i primenyat' kodirovanie peredachi tipa "chunked".
Esli postupilo soobshchenie s polem Content-Length i zakodirovannoe
s primeneniem kodirovaniya peredachi "chunked", to pole
Content-Length DOLZHNO ignorirovat'sya.
Esli pole Content-Length prisutstvuet v soobshchenii, kotoroe
dopuskaet nalichie tela soobshcheniya (message-body), to znachenie polya
DOLZHNO tochno sootvetstvovat' chislu oktetov v tele soobshcheniya.
HTTP/1.1 agenty pol'zovatelya DOLZHNY informirovat' pol'zovatelya v
sluchae polucheniya i obnaruzheniya nedopustimoj dliny.
4.5 Obshchie polya zagolovka.
Imeetsya neskol'ko polej zagolovka, kotorye primenyayutsya kak dlya
soobshchenij zaprosov, tak i dlya soobshchenij otvetov, no kotorye ne
primenyayutsya k peredavaemomu ob容ktu. |ti polya zagolovka
primenyayutsya tol'ko k peredavaemomu soobshcheniyu.
general-header = Cache-Control ; Razdel 14.9
| Connection ; Razdel 14.10
| Date ; Razdel 14.19
| Pragma ; Razdel 14.32
| Transfer-Encoding ; Razdel 14.40
| Upgrade ; Razdel 14.41
| Via ; Razdel 14.44
Imena obshchih polej zagolovka (general-header fields) mogut byt'
nadezhno rasshireny tol'ko v sochetanii s izmeneniem versii protokola.
Odnako, novye ili eksperimental'nye polya zagolovka mogut poluchit'
semantiku obshchih polej zagolovka (general-header fields), esli vse
storony soedineniya raspoznayut ih kak obshchie polya zagolovka.
Neraspoznannye polya zagolovka obrabatyvayutsya kak polya zagolovka
ob容kta (entity-header).
Soobshchenie zaprosa ot klienta k serveru soderzhit v pervoj stroke:
metod, kotoryj nuzhno primenit' k resursu, identifikator resursa
i ispol'zuemuyu versiyu protokola.
Request = Request-Line ; Razdel 5.1
*( general-header ; Razdel 4.5
| request-header ; Razdel 5.3
| entity-header ) ; Razdel 7.1
CRLF
[ message-body ] ; Razdel 7.2
5.1 Stroka zaprosa (Request-Line).
Stroka zaprosa (Request-Line) nachinaetsya s leksemy metoda, zatem
sleduet zaprashivaemyj URI (Request-URI), versiya protokola i CRLF.
|ti elementy razdelyayutsya SP. V stroke zaprosa (Request-Line) ne
dopustimy CR i LF, isklyuchenie sostavlyaet konechnaya
posledovatel'nost' CRLF.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Leksema metoda ukazyvaet metod, kotoryj nuzhno primenit' k resursu,
identificirovannomu zaprashivaemym URI (Request-URI). Metod
chuvstvitelen k registru.
Method = "OPTIONS" ; Razdel 9.2
| "GET" ; Razdel 9.3
| "HEAD" ; Razdel 9.4
| "POST" ; Razdel 9.5
| "PUT" ; Razdel 9.6
| "DELETE" ; Razdel 9.7
| "TRACE" ; Razdel 9.8
| extension-method
extension-method = token
Spisok metodov, primenimyh k resursu, mozhet byt' ukazan v pole
zagolovka Allow (razdel 14.7). Vozvrashaemyj kod sostoyaniya otveta
vsegda soobshchaet klientu, dopustim li metod dlya resursa v nastoyashchee
vremya, tak kak nabor dopustimyh metodov mozhet izmenyat'sya
dinamicheski. Serveram SLEDUET vozvratit' kod sostoyaniya 405 (Metod
ne dozvolen, Method Not Allowed), esli metod izvesten serveru, no
ne primenim dlya zaproshennogo resursa, i 501 (Ne realizovano, Not
Implemented), esli metod ne raspoznan ili ne realizovan serverom.
Spisok metodov, izvestnyh serveru, mozhet byt' ukazan v pole
zagolovka otveta Public (razdel 14.35).
Metody GET i HEAD DOLZHNY podderzhivat'sya vsemi universal'nymi
(general-purpose) serverami. Ostal'nye metody opcional'ny; odnako,
esli vysheupomyanutye metody realizovany, to oni DOLZHNY imet'
semantiku, opisannuyu v razdele 9.
5.1.2 Zaprashivaemyj URI (Request-URI).
Zaprashivaemyj URI (Request-URI) - eto Edinoobraznyj Identifikator
Resursa (URL, razdel 3.2), kotoryj identificiruet resurs zaprosa.
Request-URI = "*" | absoluteURI | abs_path
Tri opcii dlya zaprashivaemogo URI (Request-URI) zavisyat ot
haraktera zaprosa. Zvezdochka "*" oznachaet, chto zapros obrashchaetsya
ne k specificheskomu resursu, a k serveru neposredstvenno, i
dopuskaetsya tol'ko v tom sluchae, kogda ispol'zuemyj metod ne
obyazatel'no obrashchaetsya k resursu.
V kachestve primera:
OPTIONS * HTTP/1.1
absoluteURI neobhodim, kogda zapros proizvoditsya cherez
proksi-server. Proksi-server perenapravlyaet zapros na server ili
obsluzhivaet ego, pol'zuyas' keshem, i vozvrashchaet otvet. Obratite
vnimanie, chto proksi-server MOZHET pereslat' zapros drugomu
proksi-serveru ili neposredstvenno serveru, opredelennomu
absoluteURI. CHtoby izbezhat' zaciklivaniya zaprosa proksi-server
DOLZHEN byt' sposoben raspoznavat' vse imena servera, vklyuchaya lyubye
psevdonimy, lokal'nye raznovidnosti, i chislovye IP adresa.
Request-Line mozhet byt', naprimer, takim:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
CHtoby obespechit' perehod k absoluteURI vo vseh zaprosah v budushchih
versiyah HTTP, vse HTTP/1.1 servery DOLZHNY prinimat' absoluteURI
v zaprosah, hotya HTTP/1.1 klienty budut generirovat' ih tol'ko v
zaprosah k proksi-serveram.
Naibolee obshchaya forma Request-URI - ta, kotoraya ispol'zuetsya dlya
identifikacii resursa na pervonachal'nom servere ili shlyuze. V etom
sluchae absolyutnyj put' URI (smotrite razdel 3.2.1, abs_path)
DOLZHEN byt' peredan kak Request-URI, a setevoe raspolozhenie URI
(net_loc) DOLZHNO byt' peredano v pole zagolovka Host. Dlya
poslednego primera klient, zhelayushchij poluchit' resurs
neposredstvenno s pervonachal'nogo servera dolzhen sozdat' TCP
soedinenie na 80 port hosta "www.w3.org" i poslat' stroki:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
i dalee ostatok zaprosa. Obratite vnimanie, chto absolyutnyj put' ne
mozhet byt' pustym; esli original'nyj URI pust, to on DOLZHEN
zaprashivat'sya kak "/" (kornevoj katalog servera).
Esli proksi-server poluchaet zapros bez puti v Request-URI, i metod
zaprosa dopuskaet formu zaprosa "*", to poslednij proksi-server v
cepochke zaprosov DOLZHEN peredat' zapros, v kotorom Request-URI
raven "*". Naprimer zapros
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
byl by peredan proksi-serverom v vide
OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001
posle soedineniya s portom 8001 hosta "www.ics.uci.edu".
Request-URI peredaetsya v formate, opredelennom v razdele 3.2.1.
Pervonachal'nyj server DOLZHEN dekodirovat' Request-URI, chtoby
pravil'no interpretirovat' zapros. Serveram SLEDUET otvechat' na
nedopustimye Request-URI sootvetstvuyushchim kodom sostoyaniya.
V zaprosah, kotorye peredayutsya dalee, proksi-servera nikogda NE
DOLZHNY perezapisyvat' chast' "abs_path" zaprashivaemogo URI
(Request-URI), za isklyucheniem sluchaya, otmechennogo vyshe, kogda
pustoj abs_path zamenyaetsya na "*", nezavisimo ot vnutrennej
realizacii proksi-servera.
Obratite vnimanie: pravilo "nichto ne perezapisyvat'"
predohranyaet proksi-servera ot izmeneniya znacheniya zaprosa,
v kotorom pervonachal'nyj server nepravil'no ispol'zuet ne
zarezervirovannye simvoly URL dlya svoih celej. Realizatoram
sleduet znat', chto nekotorye do-HTTP/1.1 proksi-servera, kak
izvestno, perezapisyvali Request-URI.
5.2 Resurs, identificiruemyj zaprosom.
Pervonachal'nye HTTP/1.1 servera DOLZHNY uchityvat', chto tochnyj
resurs, identificirovannyj internet-zaprosom opredelyaetsya
issledovaniem kak Request-URI, tak i polya zagolovka Host.
Pervonachal'nyj server, kotoryj ne pozvolyaet resursam otlichat'sya po
zaproshennomu hostu (host), MOZHET ignorirovat' znachenie polya
zagolovka Host. (No smotrite razdel 19.5.1 dlya drugih trebovanij
po podderzhke Host v HTTP/1.1).
Pervonachal'nyj server, kotoryj razlichaet resursy, osnovannye na
zaproshennom hoste (inogda nazyvaemye virtual'nymi hostami ili
vanity hostnames) DOLZHEN ispol'zovat' sleduyushchie pravila dlya
opredeleniya zaproshennogo v HTTP/1.1 zaprose resursa:
1. Esli Request-URI - eto absoluteURI, to host - eto chast'
Request-URI. Lyuboe znachenie polya zagolovka Host v zaprose
DOLZHNO ignorirovat'sya.
2. Esli Request-URI - ne absoluteURI, a zapros soderzhit pole
zagolovka Host, to host opredelyaetsya znacheniem polya
zagolovka Host.
3. Esli hosta, opredelennogo pravilami 1 ili 2 ne sushchestvuet na
servere, kod sostoyaniya otveta DOLZHEN byt' 400 (Isporchennyj
Zapros, Bad Request).
Poluchateli HTTP/1.0 zaprosa, v kotorom nedostaet polya zagolovka
Host, MOGUT pytat'sya ispol'zovat' evristiku (naprimer, issledovat'
put' v URI na predmet unikal'nosti na kakom-libo iz hostov) chtoby
opredelit' kakoj tochno resurs zaprashivaetsya.
5.3 Polya zagolovka zaprosa.
Polya zagolovka zaprosa pozvolyayut klientu peredavat' serveru
dopolnitel'nuyu informaciyu o zaprose i o samom kliente. |ti polya
dejstvuyut kak modifikatory zaprosa s semantikoj, ekvivalentnoj
parametram vyzova metodov v yazykah programmirovaniya.
request-header = Accept ; Razdel 14.1
| Accept-Charset ; Razdel 14.2
| Accept-Encoding ; Razdel 14.3
| Accept-Language ; Razdel 14.4
| Authorization ; Razdel 14.8
| From ; Razdel 14.22
| Host ; Razdel 14.23
| If-Modified-Since ; Razdel 14.24
| If-Match ; Razdel 14.25
| If-None-Match ; Razdel 14.26
| If-Range ; Razdel 14.27
| If-Unmodified-Since ; Razdel 14.28
| Max-Forwards ; Razdel 14.31
| Proxy-Authorization ; Razdel 14.34
| Range ; Razdel 14.36
| Referer ; Razdel 14.37
| User-Agent ; Razdel 14.42
Imena polej zagolovka zaprosa (Request-header) mogut byt' nadezhno
rasshireny tol'ko v sochetanii s izmeneniem versii protokola.
Odnako, novye ili eksperimental'nye polya zagolovka mogut poluchit'
semantiku polej zagolovka zaprosa (Request-header), esli vse
storony soedineniya raspoznayut ih kak polya zagolovka zaprosa
(Request-header). Neraspoznannye polya zagolovka obrabatyvayutsya
kak polya zagolovka ob容kta (entity-header).
Posle polucheniya i interpretacii soobshcheniya zaprosa, server otvechaet
soobshcheniem HTTP otveta.
Response = Status-Line ; Razdel 6.1
*( general-header ; Razdel 4.5
| response-header ; Razdel 6.2
| entity-header ) ; Razdel 7.1
CRLF
[ message-body ] ; Razdel 7.2
6.1 Stroka sostoyaniya (Status-Line).
Pervaya stroka otveta - eto stroka sostoyaniya (Status-Line). Ona
sostoit iz versii protokola (HTTP-Version), chislovogo koda
sostoyaniya (Status-Code) i poyasnyayushchej frazy (Reason-Phrase),
razdelennyh simvolami SP. CR i LF ne dopustimy v
Status-Line, za isklyucheniem konechnoj posledovatel'nosti CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1 Kod sostoyaniya i poyasnyayushchaya fraza.
|lement kod sostoyaniya (Status-Code) - eto celochislennyj
trehrazryadnyj kod rezul'tata ponimaniya i udovletvoreniya zaprosa.
|ti kody polnost'yu opredeleny v razdele 10. Poyasnyayushchaya fraza
(Reason-Phrase) prednaznachena dlya korotkogo tekstovogo opisaniya
koda sostoyaniya. Kod sostoyaniya (Status-Code) prednaznachen dlya
ispol'zovaniya avtomatami, a poyasnyayushchaya fraza prednaznachena dlya
zhivyh pol'zovatelej. Ot klienta ne trebuetsya issledovat' ili
otobrazhat' poyasnyayushchuyu frazu (Reason-Phrase).
Pervaya cifra koda sostoyaniya opredelyaet klass otveta. Poslednie dve
cifry ne imeyut opredelennoj roli v klassifikacii. Imeetsya 5
znachenij pervoj cifry:
o 1xx: Informacionnye kody - zapros poluchen, prodolzhaetsya
obrabotka.
o 2xx: Uspeshnye kody - dejstvie bylo uspeshno polucheno, ponyato
i obrabotano.
o 3xx: Kody perenapravleniya - dlya vypolneniya zaprosa dolzhny
byt' predprinyaty dal'nejshie dejstviya.
o 4xx: Kody oshibok klienta - zapros imeet plohoj sintaksis
ili ne mozhet byt' vypolnen.
o 5xx: Kody oshibok servera - server ne v sostoyanii vypolnit'
dopustimyj zapros.
Konkretnye znacheniya chislovyh kodov sostoyaniya, opredelennyh v
HTTP/1.1, i primernyj nabor sootvetstvuyushchih poyasnyayushchih fraz
(Reason-Phrase) privodyatsya nizhe. Poyasnyayushchie frazy (Reason-Phrase),
perechislennye zdes' yavlyayutsya rekomenduemymi, no mogut byt'
zameneny na ekvivalentnye bez vozdejstviya na protokol.
Status-Code = "100" ; Prodolzhat', Continue
| "101" ; Pereklyuchenie protokolov,
; Switching Protocols
| "200" ; OK
| "201" ; Sozdan, Created
| "202" ; Prinyato, Accepted
| "203" ; Ne avtorskaya informaciya,
; Non-Authoritative Information
| "204" ; Net soderzhimogo, No Content
| "205" ; Sbrosit' soderzhimoe, Reset
; Content
| "206" ; CHastichnoe soderzhimoe, Partial
; Content
| "300" ; Mnozhestvennyj vybor, Multiple
; Choices
| "301" ; Postoyanno perenesen, Moved
; Permanently
| "302" ; Vremenno peremeshchen, Moved
; Temporarily
| "303" ; Smotret' drugoj, See Other
| "304" ; Ne modificirovan, Not Modified
| "305" ; Ispol'zujte proksi-server, Use
; Proxy
| "400" ; Isporchennyj Zapros, Bad Request
| "401" ; Nesankcionirovanno, Unauthorized
| "402" ; Trebuetsya oplata, Payment
; Required
| "403" ; Zapreshcheno, Forbidden
| "404" ; Ne najden, Not Found
| "405" ; Metod ne dozvolen, Method Not
; Allowed
| "406" ; Ne priemlem, Not Acceptable
| "407" ; Trebuetsya ustanovlenie
; podlinnosti cherez proksi-server,
; Proxy Authentication Required
| "408" ; Isteklo vremya ozhidaniya zaprosa,
; Request Timeout
| "409" ; Konflikt, Conflict
| "410" ; Udalen, Gone
| "411" ; Trebuetsya dlina, Length Required
| "412" ; Preduslovie neverno,
; Precondition Failed
| "413" ; Ob容kt zaprosa slishkom bol'shoj,
; Request Entity Too Large
| "414" ; URI zaprosa slishkom dlinnyj,
; Request-URI Too Long
| "415" ; Nepodderzhivaemyj media tip,
; Unsupported Media Type
| "500" ; Vnutrennyaya oshibka servera,
; Internal Server Error
| "501" ; Ne realizovano, Not Implemented
| "502" ; Oshibka shlyuza, Bad Gateway
| "503" ; Servis nedostupen, Service
; Unavailable
| "504" ; Isteklo vremya ozhidaniya ot shlyuza,
; Gateway Timeout
| "505" ; Ne podderzhivaemaya versiya HTTP,
; HTTP Version Not Supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT ne vklyuchayushchij CR, LF>
Kody sostoyaniya HTTP rasshiryaemy. HTTP prilozheniyam ne trebuetsya
ponimat' znachenie vseh zaregistrirovannyh kodov sostoyaniya, hotya
takoe ponimanie ochen' zhelatel'no. Odnako, prilozheniya DOLZHNY
ponimat' klass lyubogo koda sostoyaniya, kotoryj oboznachaetsya pervoj
cifroj, i obrabatyvat' lyuboj neraspoznannyj otvet kak
ekvivalentnyj kodu sostoyaniya x00 etogo klassa, za isklyucheniem teh
sluchaev, kogda neraspoznannyj otvet NE DOLZHEN keshirovat'sya.
Naprimer, esli klientom poluchen i ne byl raspoznan kod
sostoyaniya 431, to on mozhet bezopasno schitat', chto v zaprose chto-to
bylo nepravil'no i obrabatyvat' otvet, kak esli by byl poluchen kod
sostoyaniya 400. V takih sluchayah agentam pol'zovatelya SLEDUET
predstavit' pol'zovatelyu ob容kt, vozvrashchennyj v otvete, tak kak
etot ob容kt, veroyatno, vklyuchaet chitabel'nuyu dlya cheloveka
informaciyu, kotoraya poyasnyaet neobychnoe sostoyanie.
6.2 Polya zagolovka otveta.
Polya zagolovka otveta (response-header fields) pozvolyayut serveru
peredavat' dopolnitel'nuyu informaciyu, kasayushchuyusya otveta, kotoraya
ne mozhet byt' pomeshchena v stroku sostoyaniya Status-Line. |ti polya
zagolovka dayut informaciyu o servere i o dal'nejshem dostupe k
resursu, ukazannomu etim Request-URI.
response-header = Age ; Razdel 14.6
| Location ; Razdel 14.30
| Proxy-Authenticate ; Razdel 14.33
| Public ; Razdel 14.35
| Retry-After ; Razdel 14.38
| Server ; Razdel 14.39
| Vary ; Razdel 14.43
| Warning ; Razdel 14.45
| WWW-Authenticate ; Razdel 14.46
Imena polej zagolovka otveta (Response-header) mogut byt' nadezhno
rasshireny tol'ko v sochetanii s izmeneniem versii protokola.
Odnako, novye ili eksperimental'nye polya zagolovka mogut poluchit'
semantiku polej zagolovka otveta (Response-header), esli vse
storony soedineniya raspoznayut ih kak polya zagolovka otveta
(Response-header). Neraspoznannye polya zagolovka obrabatyvayutsya
kak polya zagolovka ob容kta (entity-header).
Mnozhestvo imen polej zagolovka otveta (Response-header) mozhet byt'
nadezhno rasshireno tol'ko v kombinacii s izmeneniem versii protokola.
Odnako, novye ili eksperimental'nye polya zagolovka s semantikoj
polej zagolovka otveta MOGUT byt' dobavleny esli vse uchastniki
soedineniya raspoznayut ih kak polya zagolovka otveta. Neraspoznannye
polya zagolovka obrabatyvayutsya kak polya zagolovka ob容kta.
Soobshcheniya zaprosov i otvetov MOGUT peredat' ob容kt, esli inoe ne
ustanovleno metodom zaprosa ili kodom sostoyaniya otveta. Ob容kt
sostoit iz polej zagolovka ob容kta (entity-header) i tela ob容kta
(entity-body), hotya nekotorye otvety mogut vklyuchat' tol'ko
zagolovki ob容kta (entity-headers).
|tot razdel otnositsya kak k otpravitelyu, tak i k poluchatelyu, to
est' k klientu ili serveru, v zavisimosti ot togo, kto posylaet,
a kto poluchaet ob容kt.
7.1 Polya zagolovka ob容kta.
Polya zagolovka ob容kta (Entity-header fields) opredelyayut
opcional'nuyu metainformaciyu o tele ob容kta ili, esli telo ne
prisutstvuet, otnositel'no resursa, identificirovannogo zaprosom.
entity-header = Allow ; Razdel 14.7
| Content-Base ; Razdel 14.11
| Content-Encoding ; Razdel 14.12
| Content-Language ; Razdel 14.13
| Content-Length ; Razdel 14.14
| Content-Location ; Razdel 14.15
| Content-MD5 ; Razdel 14.16
| Content-Range ; Razdel 14.17
| Content-Type ; Razdel 14.18
| ETag ; Razdel 14.20
| Expires ; Razdel 14.21
| Last-Modified ; Razdel 14.29
| extension-header
extension-header = message-header
Mehanizm rasshireniya polej zagolovka pozvolyaet vvodit'
dopolnitel'nye polya zagolovka ob容kta (entity-header fields) ne
izmenyaya protokol, no eti polya ne mogut schitat'sya raspoznavaemymi
poluchatelem. Neraspoznannye polya zagolovka poluchatelyu SLEDUET
ignorirovat', a proksi-serveru peresylat' bez izmenenij.
Telo ob容kta (esli ono prisutstvuet) posylaetsya s HTTP zaprosom
ili otvetom i imeet format i kodirovanie, opredelyaemoe polyami
zagolovka ob容kta (entity-header fields).
entity-body = *OCTET
Telo ob容kta (entity-body) predstavleno v soobshchenii tol'ko togda,
kogda prisutstvuet telo soobshcheniya (message-body), kak opisano v
razdele 4.3. Telo ob容kta (entity-body) poluchaetsya iz tela
soobshcheniya (message-body), dekodirovaniem kodirovaniya peredachi,
ukazannogo v pole Transfer-Encoding, i kotoroe mozhet byt'
primeneno dlya garantirovaniya bezopasnoj i pravil'noj peredachi
soobshcheniya.
Kogda telo ob容kta (entity-body) vklyucheno v soobshchenie, tip dannyh
etogo tela opredelyaetsya polyami zagolovka Content-Type i
Content-Encoding. Oni opredelyayut dvuhurovnevuyu uporyadochennuyu
model' kodirovaniya:
entity-body := Content-Encoding( Content-Type( data ) )
Tip soderzhimogo (Content-Type) opredelyaet media tip osnovnyh
dannyh. Kodirovanie soderzhimogo (Content-Encoding) mozhet
ispol'zovat'sya dlya ukazaniya lyubogo dopolnitel'nogo kodirovaniya
soderzhimogo, primenennogo k dannym (obychno s cel'yu szhatiya dannyh).
Kodirovanie soderzhimogo (Content-Encoding) yavlyaetsya svojstvom
zaproshennogo resursa. Po umolchaniyu nikakogo kodirovaniya ne zadano.
V lyuboe HTTP/1.1 soobshchenie, soderzhashchee telo ob容kta (entity-body)
SLEDUET vklyuchat' pole zagolovka Content-Type, opredelyayushchee media
tip etogo tela. V tom i tol'ko v tom sluchae, kogda media tip ne
predstavlen polem Content-Type, poluchatel' MOZHET popytat'sya
predpolozhit' media tip, proveryaya soderzhimoe i/ili rasshirenie
(rasshireniya) v imeni URL, ispol'zuemogo dlya identifikacii resursa.
Esli media tip ostalsya neraspoznan, poluchatelyu SLEDUET
obrabatyvat' ego kak tip "application/octet-stream".
Dlina tela ob容kta (entity-body) - eto dlina tela soobshcheniya
(message-body), poluchennogo posle dekodirovaniya vseh kodirovanij
peredachi. Razdel 4.4 opredelyaet kak vychislyaetsya dlina tela
soobshcheniya (message-body).
8 Soedineniya (Connections).
8.1 Postoyannye soedineniya (Persistent Connections).
Do postoyannyh soedinenij dlya zaprosa kazhdogo URL ustanavlivalos'
otdel'noe TCP soedinenie, chto uvelichivalo nagruzku na HTTP servera
i vyzyvalo zagruzku Interneta. Ispol'zovanie vstroennyh
izobrazhenij i drugih svyazannyh dannyh chasto trebuet ot klienta
delat' neskol'ko zaprosov k odnomu serveru za korotkij promezhutok
vremeni. Issledovaniya problem effektivnosti takogo resheniya
dostupny v [30][27]; analiz i rezul'taty realizacii prototipa
nahodyatsya v [26].
Postoyannye HTTP soedineniya imeyut ryad preimushchestv:
o Otkrytie i zakrytie men'shego kolichestva TCP soedinenij
ekonomit vremya central'nogo processora i pamyat', ispol'zuemuyu
dlya upravlyayushchih blokov protokola TCP.
o HTTP zaprosy i otvety mozhet byt' konvejerizovany v
soedinenii. Konvejernaya obrabotka pozvolyaet klientu delat'
mnozhestvo zaprosov ne ozhidaya otveta na kazhdyj, sledovatel'no,
odinochnoe TCP soedinenie, ispol'zovanie kotorogo namnogo
bolee effektivno, teryaet men'she vremeni.
o Zagruzka seti umen'shaetsya s umen'sheniem chisla paketov,
vyzvannyh otkrytiem TCP soedinenij, i, sledovatel'no, daet
protokolu TCP dostatochnoe vremya dlya opredeleniya sostoyaniya
zagruzki seti.
o HTTP mozhet razvivat'sya bolee elegantno; tak kak oshibki mogut
soobshchat'sya bez zakrytiya TCP soedineniya v kachestve shtrafa.
Klienty, ispol'zuyushchie budushchie versii HTTP mogli by
optimistichno probovat' novye vozmozhnosti, no pri svyazi so
starym serverom, povtoryat' zapros, ispol'zuya staruyu
semantiku posle soobshcheniya ob oshibke.
HTTP realizaciyam SLEDUET realizovyvat' postoyannye soedineniya.
Znachitel'noe otlichie HTTP/1.1 ot bolee rannih versij HTTP sostoit
v tom, chto postoyannye soedineniya yavlyayutsya zadannym po umolchaniyu
povedeniem lyubogo HTTP soedineniya. To est' esli ne oboznacheno
inogo, klient mozhet schitat', chto server podderzhit postoyannoe
soedinenie.
Postoyannye soedineniya obespechivayut mehanizm, soglasno kotoromu
klient i server mogut soobshchit' o razryve TCP soedineniya. |to
signaliziruetsya pri pomoshchi ispol'zovaniya polya zagolovka
Connection. Pri poluchenii soobshcheniya o razryve soedineniya klient
NE DOLZHEN posylat' bol'she zaprosov po etomu soedineniyu.
8.1.2.1 Obsuzhdenie (Negotiation).
HTTP/1.1 server MOZHET schitat', chto HTTP/1.1 klient ne predpolagaet
podderzhivat' postoyannoe soedinenie, esli poslannyj v zaprose
zagolovok Connection soderzhit leksemu soedineniya
(connection-token) "close". Esli server reshaet zakryt' soedinenie
nemedlenno posle posylki otveta, to emu SLEDUET poslat' zagolovok
Connection, kotoryj soderzhit leksemu soedineniya (connection-token)
"close".
HTTP/1.1 klient MOZHET ozhidat', chto soedinenie ostanetsya otkrytym,
no dolzhen reshit' ostavlyat' li ego otkrytym na osnovanii togo,
soderzhit li otvet servera zagolovok Connection s leksemoj
soedineniya "close". V sluchae, esli klient ne hochet podderzhivat'
soedinenie dlya posleduyushchih zaprosov, emu SLEDUET poslat' zagolovok
Connection, soderzhashchij leksemu soedineniya "close".
Esli klient ili server posylaet leksemu zakrytiya soedineniya
"close" v zagolovke Connection, to zapros stanovitsya poslednim
v soedinenii.
Klientam i serveram NE SLEDUET schitat', chto postoyannoe soedinenie
podderzhivaetsya HTTP versiyami, men'shimi chem 1.1, esli eto ne
ukazano yavno. Smotrite razdel 19.7.1 s bolee podrobnoj informaciej
o obratnoj sovmestimosti s HTTP/1.0 klientami.
CHtoby soedinenie ostavalos' postoyannym, vse soobshcheniya,
peredavaemye po nemu dolzhny imet' samoopredelennuyu (self-defined)
dlinu soobshcheniya (to est', ne opredelyaemuyu zakrytiem soedineniya),
kak opisano v razdele 4.4.
8.1.2.2 Konvejernaya obrabotka (Pipelining).
Klient, kotoryj podderzhivaet postoyannye soedineniya MOZHET
"proizvesti konvejernuyu obrabotku" zaprosov (to est', posylat'
neskol'ko zaprosov ne ozhidaya otveta na kazhdyj). Server DOLZHEN
poslat' otvety na eti zaprosy v tom zhe samom poryadke, v kakom
byli polucheny zaprosy.
Klienty, kotorye podderzhivayut postoyannye soedineniya i proizvodyat
konvejernuyu obrabotku nemedlenno posle ustanovleniya soedineniya,
DOLZHNY byt' gotovy povtorit' soedinenie, esli pervaya popytka
konvejernoj obrabotki dala sboj. Esli klient delaet takoj povtor,
on NE DOLZHEN proizvodit' konvejernuyu obrabotku prezhde, chem uznaet,
chto soedinenie postoyannoe. Klienty DOLZHNY takzhe byt' gotovy snova
poslat' zaprosy, esli server zakryvaet soedinenie pered posylkoj
vseh sootvetstvuyushchih otvetov.
8.1.3 Proksi-servera (Proxy Servers).
Ochen' vazhno, chtoby proksi-servera pravil'no vypolnyali svojstva
polej zagolovka Connection, kak opredeleno v 14.2.1.
Proksi-server DOLZHEN soobshchat' o postoyannyh soedineniyah otdel'no
svoim klientam i otdel'no pervonachal'nym serveram (ili drugim
proksi-serveram), kotorye s nim soedineny. Kazhdoe postoyannoe
soedinenie primenyaetsya tol'ko k odnoj transportnoj svyazi.
Proksi-server NE DOLZHEN ustanavlivat' postoyannoe soedinenie s
HTTP/1.0 klientom.
8.1.4 Prakticheskie coglasheniya (Practical Considerations).
Servera obychno imeyut nekotoroe znachenie vremeni ozhidaniya, posle
kotorogo oni ne podderzhivayut neaktivnoe soedinenie. Proksi-servera
mogut delat' eto znachenie bolee vysokim, tak kak, veroyatno, klient
sdelaet bol'shee kolichestvo soedinenij cherez etot zhe server.
Ispol'zovanie postoyannyh soedinenij ne vvodit nikakih ogranichenij
na prodolzhitel'nost' etogo vremeni ozhidaniya kak dlya klienta, tak
i dlya servera.
Kogda u klienta ili servera isteklo vremya ozhidaniya, emu SLEDUET
proizvesti izyashchnoe zakrytie transportnogo soedineniya. Kak
klientam, tak i serveram SLEDUET postoyanno nablyudat' za drugoj
storonoj na predmet zakrytiya soedineniya, i sootvetstvenno
otvechat'. Esli klient ili server ne obnaruzhivaet zakrytiya
soedineniya drugoj storonoj srazu, to eto vyzyvaet ne opravdannuyu
tratu resursov seti.
Klient, server, ili proksi-server MOGUT zakryt' transportnoe
soedinenie v lyuboe vremya. Naprimer, klient MOZHET nachat' posylat'
novyj zapros v to vremya, kogda server reshaet zakryt'
"bezdejstvuyushchee" soedinenie. S tochki zreniya servera, soedinenie
zakryvaetsya, v to vremya kak ono bylo neaktivno, no s tochki zreniya
klienta, zapros proizoshel.
|to oznachaet, chto klienty, servery, i proksi-servery DOLZHNY byt'
v sostoyanii obrabatyvat' asinhronnye sobytiya zakrytiya.
Programmnomu obespecheniyu klienta SLEDUET vnov' otkryt'
transportnoe soedinenie i povtorno peredat' prervannyj zapros bez
? vzaimodejstviya s pol'zovatelem, poskol'ku metod zaprosa
idempotent (smotrite razdel 9.1.2); drugie metody NE DOLZHNY byt'
povtoreny avtomaticheski, hotya agenty pol'zovatelya MOGUT predlozhit'
operatoru vybor povtoryat' zapros, ili net.
Odnako eto avtomaticheskoe povtorenie NE SLEDUET proizvodit', esli
sboj proishodit uzhe vo vtorom zaprose.
Serveram vsegda SLEDUET otvechat' na po krajnej mere na odin zapros
v soedinenii, esli eto vozmozhno. Serveram NE SLEDUET razryvat'
soedinenie v seredine peredachi otveta, esli ne predpolagaetsya
setevoj ili klientskij otkaz.
Klientam, ispol'zuyushchim postoyannye soedineniya, SLEDUET ogranichit'
chislo odnovremennyh soedinenij, kotorye oni ustanavlivayut s dannym
serverom. Odnopol'zovatel'skomu klientu SLEDUET ustanavlivat'
maksimum 2 soedineniya s lyubym serverom ili proksi-serverom.
Proksi-serveru SLEDUET ogranichit'sya 2*N soedinenimi s drugimi
serverami ili proksi-serverami, gde N - chislo odnovremenno
aktivnyh pol'zovatelej. |ti rukovodyashchie principy prednaznacheny
dlya umen'sheniya vremeni HTTP otveta i izbezhaniya chrezmernoj zagruzki
Interneta ili drugih setej.
8.2 Trebovaniya k peredache soobshchenij.
Obshchie trebovaniya:
o HTTP/1.1 serveram SLEDUET podderzhivat' postoyannye soedineniya i
ispol'zovat' mehanizmy upravleniya potokom dannyh TCP v celyah
umen'sheniya vremennyh peregruzok, vmesto zakrytiya soedinenij,
kotorye, kak ozhidaetsya, mogut byt' povtorno ispol'zovany
klientami. Poslednyaya metodika mozhet usilivat' setevuyu zagruzku.
o HTTP/1.1 (ili bolee pozdnim) klientam, posylayushchim telo
soobshcheniya (message-body) SLEDUET kontrolirovat' setevoe
soedinenie na predmet oshibok vo vremya peredachi zaprosa. Esli
klient obnaruzhivaet oshibku, emu SLEDUET nemedlenno prekratit'
peredachu tela soobshcheniya. Esli telo posylaetsya s ispol'zovaniem
kodirovaniya "po kuskam" ("chunked", razdel 3.6), to kusok
nulevoj dliny, i pustoj zavershitel' MOGUT ispol'zovat'sya dlya
indikacii prezhdevremennogo konca soobshcheniya. Esli telu
predshestvoval zagolovok Content-Length, klient DOLZHEN zakryt'
soedinenie.
o HTTP/1.1 (ili bolee pozdnij) klient DOLZHEN byt' gotov prinyat'
otvet s kodom sostoyaniya 100 (Prodolzhat', Continue),
predshestvuyushchij osnovnomu otvetu.
o HTTP/1.1 (ili bolee pozdnij) server, kotoryj poluchaet zapros ot
HTTP/1.0 (ili bolee rannego) klienta NE DOLZHEN peredat' otvet
s kodom sostoyaniya 100 (Prodolzhat', Continue); emu SLEDUET libo
ozhidat' poka zapros budet vypolnen obychnym obrazom (to est' bez
ispol'zovaniya prervannogo zaprosa), libo prezhdevremenno zakryt'
soedinenie.
Posle polucheniya metoda, podchinennogo etim trebovaniyam, ot HTTP/1.1
(ili bolee pozdnego) klienta, HTTP/1.1 (ili bolee pozdnij) server
DOLZHEN libo otvetit' kodom sostoyaniya 100 (Prodolzhat', Continue) i
prodolzhat' chtenie vhodnogo potoka, libo otvetit' oshibochnym kodom
sostoyaniya. Esli server otvetil oshibochnym kodom sostoyaniya, to on
MOZHET libo zakryt' transportnoe soedinenie (TCP), libo prodolzhat'
chitat' i otbrasyvat' ostavshuyusya chast' zaprosa. On NE DOLZHEN
vypolnyat' zaproshennyj metod, esli vozvratil kod sostoyaniya oshibki.
Klientam SLEDUET pomnit' nomer versii HTTP, ispol'zuemoj serverom
po krajnej mere v poslednij raz; esli HTTP/1.1 klient vstrechal
HTTP/1.1 ili bolee pozdnij otvet ot servera, i vidit zakrytie
soedineniya pered polucheniem kakogo-libo koda sostoyaniya ot servera,
klientu SLEDUET povtorit' zapros bez vzaimodejstviya s
? pol'zovatelem, poskol'ku metod zaprosa idempotent (smotrite
razdel 9.1.2); drugie metody NE DOLZHNY byt' povtoreny
avtomaticheski, hotya agenty pol'zovatelya MOGUT predlozhit' operatoru
vybor povtoryat' zapros, ili net. Esli klient povtoryaet zapros,
to on
o DOLZHEN snachala poslat' polya zagolovka zaprosa, a zatem
o DOLZHEN ozhidat' otveta servera s kodom 100 (Prodolzhat',
Continue), a zatem prodolzhat', ili s kodom sostoyaniya oshibki.
Esli HTTP/1.1 klient ne vstrechal otveta servera versii HTTP/1.1
ili bolee pozdnej, to emu sleduet schitat', chto server realizuet
HTTP/1.0 ili bolee staryj protokol i ne ispol'zovat' otvety s
kodom sostoyaniya 100 (Prodolzhat', Continue). Esli v takoj situacii
klient vidit zakrytie soedineniya pered polucheniem kakogo-libo
otveta s kodom sostoyaniya ot servera, to emu SLEDUET povtorit'
zapros. Esli klient povtoryaet zapros k etomu HTTP/1.0 serveru, to
? on dolzhen ispol'zovat' sleduyushchij "binary exponential backoff"
algoritm, chtoby byt' uverennym v poluchenii nadezhnogo otveta:
1. Inicializirovat' novoe soedinenie s serverom.
2. Peredat' zagolovki zaprosa (request-headers).
3. Inicializirovat' peremennuyu R primernym vremenem peredachi
informacii na server i obratno (naprimer na osnovanii vremeni
ustanovleniya soedineniya), ili postoyannym znachenie v 5 sekund,
esli vremya peredachi ne dostupno.
4. Vychislit' T = R * (2**N), gde N - chislo predydushchih povtorov
etogo zaprosa.
5. Libo dozhdat'sya ot servera otveta s kodom oshibki, libo prosto
vyzhdat' T sekund (smotrya chto proizojdet ran'she).
6. Esli otveta s kodom oshibki ne polucheno, posle T sekund peredat'
telo zaprosa.
7. Esli klient obnaruzhivaet, chto soedinenie bylo zakryto
prezhdevremenno, to emu nuzhno povtoryat' nachinaya s shaga 1, poka
zapros ne budet prinyat, libo poka ne budet poluchen oshibochnyj
otvet, libo poka u pol'zovatelya ne konchitsya terpenie i on ne
zavershit process povtoreniya.
Nezavisimo ot togo, kakaya versiya HTTP realizovana serverom, esli
klient poluchaet oshibochnyj kod sostoyaniya, to on
o NE DOLZHEN prodolzhat' i
o DOLZHEN zakryt' soedinenie, esli on ne zavershil posylku
soobshcheniya.
HTTP/1.1 (ili bolee pozdnemu) klientu, kotoryj obnaruzhivaet
zakrytie soedineniya posle polucheniya otveta s kodom sostoyaniya 100
(Prodolzhat', Continue), no do polucheniya otveta s drugim kodom
sostoyaniya, SLEDUET povtorit' zapros, no uzhe ne ozhidat' otveta s
kodom sostoyaniya 100 (Prodolzhat', Continue) (no on MOZHET sdelat'
tak, esli eto uproshchaet realizaciyu).
9 Opredeleniya metodov (Method Definitions).
Nabor obshchih metodov dlya HTTP/1.1 privoditsya nizhe. Hotya etot nabor
mozhet byt' rasshiren, nel'zya schitat', chto dopolnitel'nye metody
imeyut odinnakovuyu semantiku, esli oni yavlyayutsya rasshireniyami
raznyh klientov i serverov.
Pole zagolovka zaprosa Host (razdel 14.23) DOLZHNO soprovozhdat'
vse HTTP/1.1 zaprosy.
?9.1 Bezopasnye i Idempotent metody.
Programmistam sleduet ponimat', chto programmnoe obespechenie pri
vzaimodejstvii s Internetom predstavlyaet pol'zovatelya, i programme
sleduet informirovat' pol'zovatelya o lyubyh dejstviyah, kotorye on
mozhet proizvesti, no kotorye mogut imet' nepredskazuemoe znachenie
dlya nego ili drugih lic.
V chastnosti bylo prinyato soglashenie, chto metody GET i HEAD nikogda
ne dolzhny imet' inogo znacheniya, krome zagruzki. |ti metody sleduet
rassmatrivat' kak "bezopasnye". |to pozvolyaet agentam pol'zovatelya
predstavlyat' drugie metody, takie kak POST, PUT i DELETE, takim
obrazom, chtoby pol'zovatel' byl proinformirovan o tom, chto on
zaprashivaet vypolnenie potencial'no opasnogo dejstviya.
Estestvenno, ne vozmozhno garantirovat', chto server ne generiruet
pobochnye effekty v rezul'tate vypolneniya zaprosa GET; fakticheski,
nekotorye dinamicheskie resursy soderzhat takuyu vozmozhnost'. Vazhnoe
razlichie zdes' v tom, chto ne pol'zovatel' zaprashivaet pobochnye
effekty, i, sledovatel'no, pol'zovatel' ne mozhet nesti
otvetstvennost' za nih.
?9.1.2 Idempotent metody.
Metody mogut takzhe obladat' svojstvom "idempotence" v tom smysle,
chto pobochnye effekty ot N > 0 identichnyh zaprosov takie zhe, kak
ot odinochnogo zaprosa (za isklyuchenie oshibok i problem
ustarevaniya). Metody GET, HEAD, PUT i DELETE obladayut dannym
svojstvom.
Metod OPTIONS predstavlyaet zapros informacii ob opciyah soedineniya,
dostupnyh v cepochke zaprosov/otvetov, identificiruemoj
zaprashivaemym URI (Request-URI). |tot metod pozvolyaet klientu
opredelyat' opcii i/ili trebovaniya, svyazannye s resursom, ili
vozmozhnostyami servera, no ne proizvodya nikakih dejstvij nad
resursom i ne iniciiruya ego zagruzku.
Esli otvet servera - eto ne soobshchenie ob oshibke, to otvet NE
DOLZHEN soderzhat' inoj informacii ob容kta, krome toj, kotoruyu mozhno
rassmatrivat' kak opcii soedineniya (naprimer Allow - mozhno
rassmatrivat' kak opciyu soedineniya, a Content-Type - net). Otvety
na etot metod ne keshiruyutsya.
Esli zaprashivaemyj URI (Request-URI) - zvezdochka ("*"), to zapros
OPTIONS prednaznachen dlya obrashcheniya k serveru v celom. Esli kod
sostoyaniya v otvete - 200, to otvetu SLEDUET soderzhat' lyubye polya
zagolovka, kotorye ukazyvayut opcional'nye vozmozhnosti, realizuemye
serverom (naprimer, Public), vklyuchaya lyubye rasshireniya, ne
opredelennye dannoj specifikaciej, v dopolnenie k sootvetstvuyushchim
obshchim polyam ili polyam zagolovka otveta (response-header). Kak
opisano v razdele 5.1.2, zapros "OPTIONS *" mozhet byt' primenen
cherez proksi-server s opredeleniem adresuemogo servera v
zaprashivaemom URI (Request-URI) s pustym putem.
Esli zaprashivaemyj URI (Request-URI) ne zvezdochka ("*"), to zapros
OPTIONS primenyaetsya k opciyam, kotorye dostupny pri soedinenii s
ukazannym resursom. Esli kod sostoyaniya otveta - 200, to otvetu
SLEDUET soderzhat' lyubye polya zagolovka, kotorye ukazyvayut
opcional'nye vozmozhnosti, realizuemye serverom i primenimye k
ukazannomu resursu (naprimer, Allow), vklyuchaya lyubye rasshireniya, ne
opredelennye dannoj specifikaciej, v dopolnenie k sootvetstvuyushchim
obshchim polyam ili polyam zagolovka otveta (response-header). Esli
zapros OPTIONS peredaetsya cherez proksi-server, to poslednij
redaktiruet otvet, isklyuchaya te opcii, kotorye ne predusmotreny
vozmozhnosti etogo proksi-servera.
Metod GET pozvolyaet poluchat' lyubuyu informaciyu (v forme ob容kta),
identificirovannuyu zaprashivaemym URI (Request-URI). Esli
zaprashivaemyj URI (Request-URI) obrashchaetsya k processu,
proizvodyashchemu dannye, to v kachestve ob容kta otveta dolzhny byt'
vozvrashcheny proizvedennye dannye, a ne ishodnyj tekst processa,
esli sam process ne vyvodit ishodnyj tekst.
Razlichaetsya "uslovnyj GET" ("conditional GET"), pri kotorom
soobshchenie zaprosa vklyuchaet polya zagolovka If-Modified-Since,
If-Unmodified-Since, If-Match, If-None-Match, ili If-Range.
Uslovnyj metod GET zaprashivaet peredachu ob容kta, tol'ko esli on
udovletvoryaet usloviyam, opisannym v uslovnyh polyah zagolovka.
Uslovnyj metod GET prednaznachen dlya umen'sheniya nenuzhnoj zagruzki
seti, i pozvolyaet obnovlyat' keshirovannye ob容kty bez ispol'zovaniya
neskol'kih zaprosov ili peresylki dannyh, uzhe sohranennyh
klientom.
Razlichaetsya takzhe "chastichnyj GET" ("partial GET"), pri kotorom
soobshchenie zaprosa vklyuchaet pole zagolovka Range. CHastichnyj GET
zaprashivaet peredachu tol'ko chasti ob容kta, kak opisano v razdele
14.36. CHastichnyj metod GET prednaznachen dlya umen'sheniya nenuzhnoj
zagruzki seti, i pozvolyaet sobirat' ob容kty iz chastej, bez
peredachi chastej dannyh, uzhe sohranennyh klientom.
Otvet na zapros GET keshiruem togda i tol'ko togda, kogda on
otvechaet trebovaniyam HTTP keshirovaniya, opisannym v razdele 13.
Metod HEAD identichen GET, za isklyucheniem togo, chto server NE
DOLZHEN vozvrashchat' v otvete telo soobshcheniya (message-body).
Metainformacii, soderzhashchejsya v HTTP zagolovkah otveta na zapros
HEAD SLEDUET byt' identichnoj informacii, predstavlyaemoj v otvet
na zapros GET. |tot metod mozhet ispol'zovat'sya dlya polucheniya
metainformacii ob ob容kte zaprosa bez neposredstvennoj peresylki
tela ob容kta (entity-body). |tot metod chasto ispol'zuetsya dlya
testirovaniya gipertekstovyh svyazej v celyah proverki pravil'nosti,
dostizhimosti, i vremeni modifikacii.
Otvet na zapros HEAD mozhet byt' keshiruemym v tom smysle, chto
informaciya, soderzhashchayasya v otvete mozhet ispol'zovat'sya dlya
modificikacii predvaritel'no keshirovannogo ob容kta iz etogo
resursa. Esli novye znacheniya polya ukazyvayut, chto keshiruemyj
ob容kt otlichaetsya ot tekushchego ob容kta (po takim parametram, kak
Content-Length, Content-MD5, ETag ili Last-Modified), to kesh
DOLZHEN obrabatyvat' soderzhimoe kak prosrochennoe.
Metod POST ispol'zuetsya dlya zaprosa, pri kotorom adresuemyj server
prinimaet ob容kt, vklyuchennyj v zapros, kak novoe podchinenie
resursa, identificirovannogo zaprashivaemym URI (Request-URI) v
stroke zaprosa (Request-Line). POST razrabotan dlya togo, chtoby
obshchim metodom realizovat' sleduyushchie funkcii:
o Annotaciya sushchestvuyushchih resursov;
o Registraciya soobshcheniya na elektronnoj doske ob座avlenij
(bulletin board), v konferencii novostej (newsgroup), spiske
rassylki (mailing list), ili podobnoj gruppe statej;
o Peredacha bloka dannyh, naprimer rezul'tat vvoda v forme,
processu obrabotki;
o Rasshirenie bazy dannyh posredstvom konkateniruyushchej operacii
(append operation).
Fakticheski funkciya, vypolnyaemaya metodom POST, opredelyaetsya
serverom i obychno zavisit ot zaprashivaemogo URI (Request-URI).
Ob容kt, peredavaemyj metodom POST, otnositsya k etomu URI takim zhe
obrazom, kak fajl otnositsya k katalogu, v kotorom on nahoditsya,
stat'ya otnositsya k konferencii novostej (newsgroup), v kotoroj ona
zaregistrirovana, a zapis' otnositsya k baze dannyh.
Dejstvie, vypolnyaemoe metodom POST mozhet ne davat' v kachestve
rezul'tata resurs, kotoryj mozhno bylo by identificirovat' URI. V
etom sluchae, v zavisimosti ot togo, vklyuchaet li otvet ob容kt,
opisyvayushchij rezul'tat, ili net, kod sostoyaniya v otvete mozhet byt'
kak 200 (OK), tak i 204 (Net soderzhimogo, No Content).
Esli resurs byl sozdan na pervonachal'nom servere, otvetu SLEDUET
soderzhat' kod sostoyaniya 201 (Sozdan, Created) i vklyuchat' ob容kt,
kotoryj opisyvaet sostoyanie zaprosa i ssylaetsya na novyj resurs,
a takzhe zagolovok Location (smotrite razdel 14.30).
Otvety na etot metod ne keshiruemy, esli otvet ne vklyuchaet
sootvetstvuyushchie polya zagolovka Cache-Control ili Expires. Odnako,
otvet s kodom sostoyaniya 303 (Smotret' drugoj, See Other) mozhet
ispol'zovat'sya dlya perenapravleniya agenta pol'zovatelya dlya
zagruzki keshiruemogo resursa.
Zaprosy POST dolzhny otvechat' trebovaniyam peredachi soobshcheniya,
izlozhennym v razdele 8.2.
Zaprosy s metodom PUT, kotorye soderzhat ob容kt, sohranyayutsya pod
zaprashivaemym URI (Request-URI). Esli Request-URI obrashchaetsya k uzhe
sushchestvuyushchemu resursu, vklyuchennyj ob容kt SLEDUET rassmatrivat' kak
modificirovannuyu versiyu ob容kta, nahodyashchegosya na pervonachal'nom
servere. Esli Request-URI ne ukazyvaet na sushchestvuyushchij resurs, i
mozhet interpretirovat'sya agentom pol'zovatelya kak novyj resurs dlya
zaprosov, pervonachal'nyj server mozhet sozdat' resurs s dannym URI.
Esli novyj resurs sozdan, to pervonachal'nyj server DOLZHEN soobshchit'
agentu pol'zovatelya ob etom posredstvom otveta s kodom sostoyaniya
201 (Sozdan, Created). Esli sushchestvuyushchij resurs modificirovan, to
dlya ukazaniya uspeshnogo zaversheniya zaprosa SLEDUET poslat' otvet s
kodom sostoyaniya libo 200 (OK), libo 204 (Net soderzhimogo, No
Content). Esli resurs ne mozhet byt' sozdan ili izmenen dlya
zaprashivaemogo URI (Request-URI), to SLEDUET poslat' otvet,
otrazhayushchij harakter problemy. Poluchatel' ob容kta NE DOLZHEN
ignorirovat' zagolovkov Content-* (naprimer Content-Range),
kotoryh ne ponimaet ili ne realizuet, a DOLZHEN v dannom sluchae
vozvratit' otvet s kodom sostoyaniya 501 (Ne realizovano, Not
Implemented).
Esli zapros peredaetsya cherez kesh i zaprashivaemyj URI (Request-URI)
identificiruet odin ili neskol'ko keshirovannyh v nastoyashchee vremya
ob容ktov, to vhozhdeniya v kesh etih ob容ktov dolzhny obrabatyvat'sya
kak prosrochennye. Otvety na etot metod ne keshiruemy.
Fundamental'noe razlichie mezhdu POST i PUT zaprosami, otrazheno v
razlichnom znachenii zaprashivaemogo URI (Request-URI). URI v zaprose
POST identificiruet resurs, kotoryj obrabatyvaet vklyuchennyj
ob容kt. |tim resursom mozhet byt' process, prinimayushchij dannye, shlyuz
k nekotoromu drugomu protokolu, ili otdel'nyj ob容kt, kotoryj
prinimaet annotacii (accepts annotations). Naprotiv, URI v zaprose
PUT identificiruet ob容kt, vklyuchennyj v zapros - agent
pol'zovatelya naznachaet dannyj URI vklyuchennomu resursu, a server NE
DOLZHEN pytat'sya primenit' zapros k nekotoromu drugomu resursu.
Esli server zhelaet primenit' zapros k drugomu URI, on DOLZHEN
poslat' otvet s kodom 301 (Peremeshchen postoyanno, Moved
Permanently); agent pol'zovatelya MOZHET zatem prinyat' sobstvennoe
reshenie otnositel'no perenaznacheniya zaprosa.
Odinochnyj resurs MOZHET byt' identificirovan neskol'kimi razlichnymi
URI. Naprimer, stat'ya mozhet imet' URI identificiruyushchij "tekushchuyu
versiyu", kotoryj otlichen ot URI, identificiruyushchego kazhduyu
specificheskuyu versiyu. V etom sluchae, zapros PUT na obshchij URI mozhet
otrazit'sya (may result) na neskol'kih drugih URI, opredelennyh
serverom proishozhdeniya.
HTTP/1.1 ne opredelyaet kakim obrazom metod PUT vozdejstvuet na
sostoyanie pervonachal'nogo servera.
Zaprosy PUT dolzhny podchinyat'sya trebovaniyam peredachi soobshchenij,
izlozhennym v razdele 8.2.
Metod DELETE zaprashivaet pervonachal'nyj server ob udalenii
resursa, identificiruemogo zaprashivaemym URI (Request-URI). |tot
metod MOZHET byt' otmenen chelovecheskim vmeshatel'stvom (ili drugimi
sredstvami) na pervonachal'nom servere. Klientu nel'zya
garantirovat', chto operaciya byla vypolnena, dazhe esli kod
sostoyaniya, vozvrashchennyj pervonachal'nym serverom ukazyvaet na to,
chto dejstvie bylo zaversheno uspeshno. Odnako, serveru NE SLEDUET
otvechat' ob uspeshnom vypolnenii, esli vo vremya otveta on
predpolagaet udalit' resurs ili peremestit' ego v nedostupnoe
polozhenie.
Uspeshnomu otvetu SLEDUET imet' kod sostoyaniya 200 (OK), esli otvet
vklyuchaet ob容kt, opisyvayushchij sostoyanie, libo imet' kod sostoyaniya
202 (Prinyato, Accepted), esli dejstvie eshche ne bylo proizvedeno,
libo imet' kod sostoyaniya 204 (Net soderzhimogo, No Content), esli
otvet soobshchaet ob uspehe (OK), no ne soderzhit ob容kta.
Esli zapros peredaetsya cherez kesh i zaprashivaemyj URI (Request-URI)
identificiruet odin ili neskol'ko keshirovannyh v nastoyashchee vremya
ob容ktov, to vhozhdeniya ih dolzhny obrabatyvat'sya kak prosrochennye.
Otvety na etot metod ne keshiruemy.
Metod TRACE ispol'zuetsya dlya vyzova udalennogo vozvrata soobshcheniya
zaprosa na urovne prilozheniya. Konechnomu poluchatelyu zaprosa SLEDUET
otrazit' poluchennoe soobshchenie obratno klientu kak telo ob容kta
otveta s kodom sostoyaniya 200 (OK). Konechnym poluchatelem yavlyaetsya
libo server proishozhdeniya, libo pervyj proksi-server, libo pervyj
shlyuz, poluchivshij nulevoe znachenie (0) v pole Max-Forwards v
zaprose (sm. razdel 14.31). Zapros TRACE NE DOLZHEN soderzhat'
ob容kta.
TRACE pozvolyaet klientu videt', chto poluchaetsya na drugom konce
cepochki zaprosov i ispol'zovat' eti dannye dlya testirovaniya ili
diagnosticheskoj informacii. Znachenie polya zagolovka Via (razdel
14.44) predstavlyaet osobyj interes, tak kak ono dejstvuet kak
sled cepochki zaprosov. Ispol'zovanie polya zagolovka Max-Forwards
pozvolyaet klientu ogranichivat' dlinu cepochki zaprosov, chto
yavlyaetsya poleznym pri testirovanii beskonechnyh ciklov v cepochke
proksi-serverov, peresylayushchih soobshcheniya.
Esli zapros uspeshno vypolnen, to otvetu SLEDUET soderzhat' vse
soobshchenie zaprosa v tele ob容kta (entity-body), a Content-Type
sleduet byt' ravnym "message/http". Otvety na etot metod NE
DOLZHNY keshirovat'sya.
10 Opisaniya kodov sostoyaniya (Status Code Definitions).
Kazhdyj kod sostoyaniya, opisannyj nizhe, vklyuchaet opisanie metoda
(ili metodov), za kotorym on mozhet sledovat' i metainformacii,
trebuemoj v otvete.
10.1 1xx - Informacionnye kody.
|tot klass kodov sostoyaniya ukazyvaet predvaritel'nyj (vremennyj)
otvet, sostoyashchij tol'ko iz stroki sostoyaniya (Status-Line) i
opcional'nyh zagolovkov, i zavershayushchijsya pustoj strokoj. Tak kak
HTTP/1.0 ne opredelyal nikakih 1xx kodov sostoyaniya, servery NE
DOLZHNY posylat' 1xx otvety HTTP/1.0 klientam, za isklyucheniem
eksperimental'nyh uslovij.
10.1.1 100 Prodolzhat', Continue.
Klient mozhet prodolzhat' zapros. |tot promezhutochnyj otvet
ispol'zuetsya, dlya togo, chtoby soobshchit' klientu, chto nachal'naya
chast' zaprosa byla poluchena i eshche ne otvergnuta serverom. Klientu
SLEDUET prodolzhit' posylku ostavshihsya dannyh zaprosa ili, esli
zapros uzhe byl vypolnen, ignorirovat' etot otvet. Server DOLZHEN
poslat' zaklyuchitel'nyj otvet posle togo, kak zapros budet
vypolnen.
10.1.2 101 Pereklyuchenie protokolov, Switching Protocols
Server ponimaet i zhelaet vypolnit' zapros klienta, esli protokol
prikladnoj programmy v etom soedinenii budet izmenen na tot,
kotoryj ukazan v pole zagolovka soobshcheniya Upgrade (razdel 14.41).
Server pereklyuchit protokol na tot, kotoryj opredelen v pole
zagolovka otveta Upgrade neposredstvenno posle pustoj stroki,
kotoraya zavershaet otvet s kodom sostoyaniya 101.
Protokol dolzhen byt' pereklyuchen tol'ko togda, kogda eto prineset
vygodu. Naprimer, pereklyuchenie na bolee novuyu versiyu HTTP vygodno
po sravneniya s ispol'zovaniem bolee staryh versij, a pereklyuchenie
na sinhronnyj protokol real'nogo vremeni mozhet byt' vygodno pri
predostavlenii resursov, kotorye ispol'zuyut takie vozmozhnosti.
10.2 2xx - Uspeshnye kody.
|tot klass kodov sostoyaniya ukazyvaet, chto zapros klienta byl
uspeshno poluchen, ponyat, i prinyat.
Zapros byl udachno vypolnen. Informaciya, vozvrashchaemaya s otvetom
zavisit ot metoda, ispol'zuemogo v zaprose. Naprimer:
GET v otvete predstavlen ob容kt, sootvetstvuyushchij zaproshennomu
resursu;
HEAD v otvete predstavleny polya zagolovka ob容kta
(entity-header), sootvetstvuyushchie zaproshennomu resursu. Telo
soobshcheniya (message-body) otsutstvuet;
POST v otvete predstavleno opisanie ob容kta ili soderzhitsya
rezul'tat dejstviya;
TRACE v otvete predstavlen ob容kt, soderzhashchij soobshchenie zaprosa,
poluchenogo konechnym serverom.
10.2.2 201 Sozdan, Created.
Zapros byl vypolnen i v rezul'tate byl sozdan novyj resurs. Novyj
sozdannyj resurs mozhet byt' vyzvan po URI (odnomu ili neskol'kim),
vozvrashchennym v ob容kte otveta; naibolee specificheskij URL dlya
resursa otdaetsya v pole zagolovka Location. Pervonachal'nyj server
DOLZHEN sozdat' resurs pered vozvratom koda sostoyaniya 201. Esli
dejstvie ne mozhet byt' vypolneno nemedlenno, server dolzhen
vozvratit' otvet s kodom sostoyaniya 202 (Prinyato, Accepted) vmesto
201.
10.2.3 202 Prinyato, Accepted.
Zapros byl prinyat dlya obrabotki, no obrabotka ne byla zavershena.
V konechnom schete zapros MOZHET byt', a MOZHET i ne byt' vypolnen,
poskol'ku on MOZHET byt' otvergnut pri fakticheskoj obrabotke.
Ne imeetsya nikakoj vozmozhnosti vtorichnoj posylki koda sostoyaniya ot
asinhronnoj operacii tipa etoj.
Otvet s kodom sostoyaniya 202 prednamerenno uklonchiv. Cel' ego
sostoit v tom, chtoby pozvolit' serveru prinyat' zapros dlya
nekotorogo drugogo processa (vozmozhno paketno-orientirovannogo
processa, kotoryj vypolnyaetsya tol'ko odin raz v den') i ne
trebovat' pri etom, chtoby soedinenie agenta pol'zovatelya s
serverom sohranyalos' do zaversheniya processa. Ob容ktu,
vozvrashchennomu s etim otvetom SLEDUET soderzhat' indikator tekushchego
sostoyaniya zaprosa i libo ssylku na monitor sostoyaniya, libo
nekotoruyu ocenku vremeni, kogda pol'zovatel' mozhet ozhidat'
zaversheniya vypolneniya zaprosa.
10.2.4 203 Ne avtorskaya informaciya, Non-Authoritative Information.
Vozvrashchennaya v zagolovke ob容kta (entity-header) metainformaciya -
eto ne original, dostupnyj na pervonachal'nom servere, a dokument,
sobrannyj iz lokal'nyh kopij ili kopij tret'ej storony.
Predstavlennyj dokument MOZHET byt' kak podmnozhestvom original'noj
versii, tak i soderzhat' svedeniya, kotorye v nej ne byli
predstavleny. Naprimer, vklyuchenie lokal'noj annotiruyushchej
informaciyu o resurse MOZHET rasshirit' metainformaciyu, izvestnuyu
pervonachal'nomu serveru. Ispol'zovanie etogo koda sostoyaniya v
otvete ne yavlyaetsya neobhodimym, no mozhet primenyat'sya togda, kogda
kod sostoyaniya otveta otlichen ot 200 (OK).
10.2.5 204 Net soderzhimogo, No Content.
Server vypolnil zapros, no net nikakoj novoj informacii, kotoruyu
mozhno poslat' obratno. Esli klient - agent pol'zovatelya, emu NE
SLEDUET izmenyat' vid dokumenta, kotoryj posluzhil prichinoj zaprosa.
|tot otvet prednaznachen prezhde vsego dlya togo, chtoby pozvolit'
vvodit' dannye dlya dejstvij, ne izmenyaya vid aktivnogo dokumenta
agenta pol'zovatelya. Otvet MOZHET vklyuchat' novuyu metainformaciyu v
forme zagolovkov ob容kta (entity-headers), kotorye SLEDUET
dobavit' k dokumentu, pokazyvaemomu v nastoyashchee vremya agentom
pol'zovatelya.
Otvet s kodom sostoyaniya 204 NE DOLZHEN soderzhat' tela soobshcheniya, i,
takim obrazom, vsegda zavershaetsya pervoj pustoj strokoj posle
polej zagolovka.
10.2.6 205 Sbrosit' soderzhimoe, Reset Content.
Server vypolnil zapros, i agentu pol'zovatelya SLEDUET otmenit'
prosmotr dokumenta, kotoryj iniciiroval zapros. |tot otvet
prednaznachen prezhde vsego dlya togo, chtoby pozvolit' vvod dannyh,
osushchestvlyaemyj pol'zovatelem, s posleduyushchej ochistkoj formy, v
kotoroj sdelan vvod, tak, chtoby pol'zovatel' mog legko
iniciirovat' sleduyushchee dejstvie vvoda. Otvet NE DOLZHEN soderzhat'
ob容kt.
10.2.7 206 CHastichnoe soderzhimoe, Partial Content.
Server vypolnil chastichnyj GET zapros resursa. Zapros dolzhen
soderzhat' pole zagolovka Range (razdel 14.36), ukazyvayushchee
zhelaemyj diapazon. Otvet DOLZHEN soderzhat' libo pole zagolovka
Content-Range (razdel 14.17), ukazyvayushchee diapazon, vklyuchennyj v
otvet, libo tip soderzhimogo (Content-Type) dolzhen byt' ravnym
"multipart/byteranges", a polya Content-Range dolzhny soderzhat'sya v
kazhdoj chasti. Esli "multipart/byteranges" ne ispol'zuetsya, pole
zagolovka Content-Length v otvete DOLZHNO sootvetstvovat'
fakticheskomu chislu oktetov (OCTETs), peredannyh v tele soobshcheniya
(message-body).
Kesh, kotoryj ne podderzhivaet zagolovki Range i Content-Range NE
DOLZHEN keshirovat' otvety s kodom sostoyaniya 206.
10.3 3xx - Perenapravlenie.
|tot klass kodov sostoyaniya ukazyvaet, chto dlya vypolneniya zaprosa
agentu pol'zovatelya neobhodimo pridprinyat' dopolnitel'noe
dejstvie. Trebuemoe dejstvie MOZHET byt' vypolneno agentom
pol'zovatelya bez vzaimodejstviya s pol'zovatelem, togda i tol'ko
togda, kogda vo vtorom zaprose ispol'zuetsya metod GET ili HEAD.
Agentu pol'zovatelya NE SLEDUET avtomaticheski perenapravlyat'
zapros bolee 5 raz, tak kak takie pereadresacii obychno ukazyvayut
beskonechnyj cikl.
10.3.1 300 Mnozhestvennyj vybor, Multiple Choices.
Zaproshennyj resurs imeet neskol'ko predstavlenij, i mozhno
ispol'zovat' lyuboe iz perechislennyh. Kazhdoe predstavlenie imeet
svoe raspolozhenie i informaciyu dlya agenta po upravleniyu dialogom
(razdel 12), predstavlennuyu takim obrazom, chto pol'zovatel' (ili
agent pol'zovatelya) mozhet vybrat' naibolee podhodyashchee
predstavlenie i perenapravit' zapros k nemu.
Esli zapros byl otlichen ot HEAD, to otvetu SLEDUET soderzhat'
ob容kt, vklyuchayushchij spisok harakteristik i adresov, iz kotorogo
pol'zovatel' ili agent pol'zovatelya mozhet vybrat' odin naibolee
podhodyashchij. Format ob容kta opredelyaetsya media tipom, ukazannym v
pole zagolovka Content-Type. V zavisimosti ot formata i
vozmozhnostej agenta pol'zovatelya, vybor naibolee podhodyashchego
predstavleniya mozhet vypolnyat'sya avtomaticheski. Odnako, eta
specifikaciya ne opredelyaet kakogo-libo standarta dlya
avtomaticheskogo vybora.
Esli server imeet predstavlenie po umolchaniyu (naibolee
predpochtitel'noe), to emu SLEDUET vklyuchit' URL etogo predstavleniya
v pole Location; agenty pol'zovatelya MOGUT ispol'zovat' znachenie
polya Location dlya avtomaticheskoj pereadresacii. |tot otvet
yavlyaetsya keshiruemym, esli ne oboznacheno inogo.
10.3.2 301 Postoyanno perenesen, Moved Permanently.
Zaproshennomu resursu byl naznachen novyj postoyannyj URI, i lyubye
budushchie ssylki na etot resurs SLEDUET vypolnyat', ispol'zuya odin iz
vozvrashchennyh URI. Klientam s vozmozhnostyami redaktirovaniya svyazej
SLEDUET avtomaticheski pereopredelit' ssylki na zaprashivaemyj URI
(Request-URI), ispol'zuya odnu ili neskol'ko novyh ssylok,
vozvrashchennyh serverom v teh mestah, gde eto vozmozhno. |tot otvet
yavlyaetsya keshiruemym, esli ne oboznacheno inogo.
Esli novyj URI - eto raspolozhenie, to otvetu SLEDUET soderzhat' URL
v pole Location. Esli metod zaprosa byl ne HEAD, to ob容ktu otveta
SLEDUET soderzhat' korotkoe gipertekstovoe primechanie s
giperssylkoj na novyj (ili novye) URI.
Esli kod sostoyaniya 301 byl poluchen v otvet na zapros, otlichnyj ot
GET ili HEAD, agent pol'zovatelya NE DOLZHEN avtomaticheski
perenaznachat' zapros, poka net podtverzhdeniya pol'zovatelya, tak kak
inache usloviya zaprosa izmenyatsya.
Obratite vnimanie: Pri avtomaticheskom perenaznachenii zaprosa
POST posle polucheniya koda sostoyaniya 301, nekotorye sushchestvuyushchie
HTTP/1.0 agenty pol'zovatelya oshibochno izmenyat metod zaprosa na
GET.
10.3.3 302 Vremenno peremeshchen, Moved Temporarily.
Zaproshennyj resurs vremenno nahoditsya pod drugim URI. Tak kak
pereadresaciya mozhet byt' izmenena v lyuboj moment, klientu SLEDUET
prodolzhat' ispol'zovat' zaprashivaemyj URI (Request-URI) v budushchih
zaprosah. Keshiruemost' etogo otveta zavisit tol'ko ot soderzhimogo
polej zagolovka Cache-Control ili Expires (esli etih polej net, to
otvet ne keshiruetsya).
Esli novyj URI - eto raspolozhenie, to otvetu SLEDUET soderzhat' URL
v pole Location. Esli metod zaprosa byl ne HEAD, to ob容ktu otveta
SLEDUET soderzhat' korotkoe gipertekstovoe primechanie s
giperssylkoj na novyj (ili novye) URI.
Esli kod sostoyaniya 302 byl poluchen v otvet na zapros, otlichnyj ot
GET ili HEAD, agent pol'zovatelya NE DOLZHEN avtomaticheski
perenaznachat' zapros, poka net podtverzhdeniya pol'zovatelya, tak kak
inache usloviya zaprosa izmenyatsya.
Obratite vnimanie: Pri avtomaticheskom perenaznachenii zaprosa
POST posle polucheniya koda sostoyaniya 302, nekotorye sushchestvuyushchie
HTTP/1.0 agenty pol'zovatelya oshibochno izmenyat metod zaprosa na
GET.
10.3.4 303 Smotret' drugoj, See Other.
Otvet na zapros mozhet byt' najden pod drugim URI i ego SLEDUET
zaprashivat', ispol'zuya metod GET dlya etogo resursa. |tot metod
sushchestvuet prezhde vsego dlya togo, chtoby proizvodit' vyvod dannyh
aktivizirovannogo metodom POST scenariya, ispol'zuya perenapravlenie
agenta pol'zovatelya na ukazannyj resurs. Novyj URI - eto ne
ssylka, zamenyayushchaya pervonachal'no zaproshennyj resurs. Otvet s kodom
sostoyaniya 303 ne keshiruem, no otvet na vtoroj (perenaznachennyj)
zapros MOZHET byt' keshirovan.
Esli novyj URI - eto raspolozhenie, to otvetu SLEDUET soderzhat' URL
v pole Location. Esli metod zaprosa byl ne HEAD, to ob容ktu otveta
SLEDUET soderzhat' korotkoe gipertekstovoe primechanie s
giperssylkoj na novyj (ili novye) URI.
10.3.5 304 Ne modificirovan, Not Modified.
Esli klient vypolnil uslovnyj GET zapros, i dostup razreshen, no
dokument ne izmenilsya, to serveru SLEDUET otvetit', ispol'zuya etot
kod sostoyaniya. Otvet NE DOLZHEN soderzhat' tela soobshcheniya.
Otvet DOLZHEN soderzhat' sleduyushchie polya zagolovka:
o Date
o ETag i/ili Content-Location, esli zagolovok byl by poslan v
otvete s kodom sostoyaniya 200 na etot zhe zapros
o Expires, Cache-Control, i/ili Vary, esli znachenie polya
(field-value) mozhet otlichat'sya ot poslannogo v lyubom
predydushchem otvete dlya takogo zhe varianta
Esli uslovnyj GET ispol'zuet strogoe sravnenie kesha (strong cache
validator) (smotret' razdel 13.3.3), otvetu NE SLEDUET soderzhat'
drugih zagolovkov ob容kta (entity-headers). Inache (to est', esli
uslovnyj GET ispol'zuet slaboe sravnenie (weak validator)), otvet
NE DOLZHEN soderzhat' drugih zagolovkov ob容kta; eto predotvrashchaet
nesoglasovannosti mezhdu keshirovannymi telami ob容ktov
(entity-bodies) i modificirovannymi zagolovkami.
Esli otvet s kodom sostoyaniya 304 ukazyvaet ob容kt, v nastoyashchee
vremya ne keshirovannyj, to kesh DOLZHEN ignorirovat' otvet i
povtorit' zapros bez uslovnogo vyrazheniya.
Esli kesh ispol'zuet poluchennyj otvet s kodom sostoyaniya 304 dlya
modificikacii vhozhdeniya kesha, kesh DOLZHEN modificirovat' vhozhdenie
tak, chtoby otrazit' lyubye novye znacheniya polej, dannye v otvete.
Otvet s kodom sostoyaniya 304 NE DOLZHEN vklyuchat' tela soobshcheniya
(message-body), i, takim obrazom, vsegda zavershaetsya pervoj pustoj
strokoj posle polej zagolovka.
10.3.6 305 Ispol'zujte proksi-server, Use Proxy.
Obrashchenie k zaproshennomu resursu DOLZHNO proizvodit'sya cherez
proksi-server, ukazannyj v pole Location. V pole Location ukazan
URL proksi-servera. Ozhidaetsya, chto poluchatel' povtorit zapros
cherez proksi-server.
10.4 4xx - Kody oshibok klienta.
Klass kodov sostoyaniya 4xx prednaznachen dlya sluchaev, kogda klient,
vozmozhno, dopustil oshibku. Za isklyucheniem otveta na zapros
HEAD, serveru SLEDUET vklyuchit' ob容kt, soderzhashchij ob座asnenie
oshibochnoj situacii, i ob座asnenie, yavlyaetsya li ona vremennoj ili
postoyannoj. |ti kody sostoyaniya primenimy k lyubomu metodu zaprosa.
Agentam pol'zovatelya SLEDUET pokazyvat' pol'zovatelyu lyuboj
vklyuchennyj ob容kt.
Obratite vnimanie: Esli klient posylaet dannye, to realizacii
servera, ispol'zuyushchej TCP, sleduet garantirovat', chto klient
podtverdil poluchenie paketa(ov), soderzhashchego otvet, prezhde chem
server zakroet soedinenie. Esli klient prodolzhaet posylat'
dannye serveru posle zakrytiya soedineniya, TCP stek servera
poshlet paket sbrosa (RST) klientu, a TCP stek klienta, v svoyu
ochered', mozhet steret' klientskie nepodtverzhdennye vhodnye
bufera prezhde, chem oni budut prochitany i interpretirovany
prilozheniem HTTP.
10.4.1 400 Isporchennyj Zapros, Bad Request.
? Zapros ne mozhet byt' ponyat serverom iz-za malformed sintaksisa.
Klientu NE SLEDUET povtoryat' zapros bez modifikacij.
10.4.2 401 Nesankcionirovanno, Unauthorized.
Zapros trebuet ustanovleniya podlinnosti pol'zovatelya. Otvet DOLZHEN
vklyuchat' pole zagolovka WWW-Authenticate (razdel 14.46),
soderzhashchee vyzov (challenge), primenimyj k zaproshennomu resursu.
Klient MOZHET povtorit' zapros s podhodyashchim polem zagolovka
Authorization (razdel 14.8). Esli zapros uzhe vklyuchaet rekomendacii
ustanovleniya podlinnosti (Authorization credentials) v pole
Authorization, to otvet s kodom sostoyaniya 401 ukazyvaet, chto v
ustanovlenii podlinnosti etim rekomendaciyam otkazano. Esli otvet
s kodom sostoyaniya 401 soderzhit tot zhe samyj vyzov, chto i
predshestvuyushchij otvet, a agent pol'zovatelya uzhe delal popytku
ustanovleniya podlinnosti po krajnej mere odin raz, to SLEDUET
pokazat' pol'zovatelyu ob容kt, kotoryj byl dan v otvete, tak kak
? etot ob容kt MOZHET vklyuchat' relevant diagnosticheskuyu informaciyu.
Ustanovlenie podlinnosti dostupa v protokole HTTP opisyvaetsya v
razdele 11.
10.4.3 402 Trebuetsya oplata, Payment Required.
|tot kod zarezervirovan dlya budushchego ispol'zovaniya.
10.4.4 403 Zapreshcheno, Forbidden.
Server ponyal zapros, no otkazyvaetsya vypolnyat' ego. Ustanovlenie
podlinnosti (Authorization) ne pomozhet, i zapros NE DOLZHEN byt'
povtoren. Esli metod zaprosa ne HEAD i server zhelaet ukazat',
pochemu zapros ne byl vypolnen, emu SLEDUET opisat' prichinu otkaza
v ob容kte. |tot kod sostoyaniya obychno ispol'zuetsya, kogda server
ne zhelaet ukazyvat' tochnuyu prichinu otkaza, ili kogda nikakoj
drugoj otvet ne podhodit.
10.4.5 404 Ne najden, Not Found.
Server ne nashel nichego, sootvetstvuyushchego dannomu zaprashivaemomu
URI (Request-URI). Nikak ne soobshchaetsya yavlyaetsya li takoe polozhenie
vremennym ili postoyannym.
Esli server ne zhelaet delat' dannuyu informaciyu dostupnoj klientu,
to vmesto etogo koda sostoyaniya mozhet ispol'zovat'sya kod sostoyaniya
403 (Zapreshcheno, Forbidden). Kod sostoyaniya 410 (Udalen, Gone)
SLEDUET ispol'zovat', esli server znaet cherez nekotoryj vnutrenne
konfiguriruemyj mehanizm, chto staryj resurs bolee nedostupen, no
ne znaet novogo adresa dlya peresylki.
10.4.6 405 Metod ne dozvolen, Method Not Allowed.
Metod, opredelennyj v stroke zaprosa (Request-Line) ne dozvoleno
primenyat' dlya resursa, identificirovannogo zaprashivaemym URI
(Request-URI). Otvet DOLZHEN vklyuchat' zagolovok Allow, soderzhashchij
spisok dopustimyh metodov dlya zaproshennogo resursa.
10.4.7 406 Ne priemlem, Not Acceptable.
Resurs, identificiruemyj zaprosom, imeet vozmozhnosti generacii
tol'ko takih ob容ktov otveta, kotorye imeyut harakteristiki
soderzhimogo (content characteristics), ne soglasuyushchiesya s
zagolovkami priema (accept headers), predstavlennymi v zaprose.
Esli eto byl ne zapros HEAD, to v otvet SLEDUET vklyuchit' ob容kt,
soderzhashchij spisok dostupnyh harakteristik ob容kta i adresa
(locations), iz kotoryh pol'zovatel' ili agent pol'zovatelya mozhet
vybrat' naibolee podhodyashchij. Format ob容kta opredeleyatsya media
tipom, predstavlennym v pole zagolovka Content-Type. V zavisimosti
ot formata i vozmozhnostej agenta pol'zovatelya, vybor naibolee
podhodyashchego varianta mozhet vypolnyat'sya avtomaticheski. Odnako, eta
specifikaciya ne opredelyaet nikakogo standarta dlya avtomaticheskogo
vybora.
Obratite vnimanie: HTTP/1.1 servery pozvolyayut vozvrashchat' otvety,
kotorye ne priemlemy soglasno zagolovkam priema (accept
headers), predstavlennym v zaprose. V nekotoryh sluchayah, eto
mozhet byt' dazhe predpochtitel'no po sravneniyu s posylkoj otveta
s kodom sostoyaniya 406. Agentam pol'zovatelya neploho by
rassmatrivat' zagolovki postupivshego otveta, chtoby opredelit',
yavlyaetsya li on priemlemym. Esli otvet nedopustim, agentu
pol'zovatelya SLEDUET vremenno ostanovit'sya, chtoby poluchit'
bol'she dannyh i sprosit' pol'zovatelya o dal'nejshih dejstviyah.
10.4.8 407 Trebuetsya ustanovlenie podlinnosti cherez proksi-server,
Proxy Authentication Required.
|tot kod podoben kodu 401 (Nesankcionirovanno, Unauthorized), no
ukazyvaet, chto klient DOLZHEN snachala ustanovit' svoyu podlinnost'
(authenticate) proksi-serveru. Proksi-server DOLZHEN vozvratit'
pole zagolovka Proxy-Authenticate (razdel 14.33), soderzhashchee
vyzov (challenge), primenyaemyj proksi-serverom dlya zaproshennogo
resursa. Klient MOZHET povtorit' zapros s podhodyashchim polem
zagolovka Proxy-Authorization (razdel 14.34). Ustanovlenie
podlinnosti dostupa v protokole HTTP opisyvaetsya v razdele 11.
10.4.9 408 Isteklo vremya ozhidaniya zaprosa, Request Timeout.
Klient ne proizvel zapros v techenie vremeni, kotoroe server gotov
zhdat'. Klient MOZHET povtorit' zapros bez modifikacij pozzhe.
10.4.10 409 Konflikt, Conflict.
Zapros ne byl vypolnen iz-za konflikta s tekushchim sostoyaniem
resursa. |tot kod pozvolyaetsya tol'ko v situaciyah, kogda ozhidaetsya,
chto pol'zovatel' mozhet reshit' konflikt i povtorno peredat' zapros.
Telu otveta SLEDUET soderzhat' dostatochnoe kolichestvo informacii
dlya pol'zovatelya, chtoby on mog raspoznat' istochnik konflikta. V
ideale, ob容kt otveta dolzhen vklyuchat' dostatochno informacii dlya
pol'zovatelya ili agenta pol'zovatelya dlya resheniya problemy; odnako
eto mozhet ne byt' vozmozhno, da i ne trebuetsya.
Konflikty, naibolee veroyatno, budut voznikat' v otvet na zapros
PUT. Esli ispol'zuetsya versifikaciya, i ob容kt, kotoryj dolzhen byt'
pomeshchen, vklyuchaet izmeneniya resursa, kotorye nahodyatsya v
protivorechii so sdelannymi ran'she kakim-libo zaprosom (tret'ej
storony), server MOZHET ispol'zovat' otvet s kodom sostoyaniya 409,
chtoby pokazat', chto on ne mozhet vypolnit' zapros. V etom sluchae,
ob容ktu otveta SLEDUET soderzhat' spisok otlichij dvuh versij v
formate, opredelennom polem zagolovka otveta Content-Type.
10.4.11 410 Udalen, Gone.
Zaproshennyj resurs bol'she ne dostupen na servere, i net nikakogo
adresa dlya perenapravleniya zaprosa. Takoe sostoyanie SLEDUET
rassmatrivat' kak postoyannoe. Klientam s vozmozhnostyami
redaktirovaniya gipersvyazej SLEDUET udalit' ssylki na zaprashivaemyj
URI (Request-URI) posle odobreniya pol'zovatelem. Esli server ne
znaet, ili ne mozhet opredelit', yavlyaetsya li takoe polozhenie
postoyannym ili net, to emu SLEDUET vmesto etogo koda ispol'zovat'
kod sostoyaniya 404 (Ne najden, Not Found). |tot otvet yavlyaetsya
keshiruemym, esli ne oboznacheno inogo.
Otvet s kodom sostoyaniya 410 prednaznachen prezhde vsego dlya togo,
chtoby pomoch' v soprovozhdenii WWW, uvedomlyaya poluchatelya, chto resurs
prednamerenno nedostupen i chto vladel'cy servera zhelayut, chtoby
udalennye svyazi, ukazyvayushchie na etot resurs byli udaleny. Takoe
sluchaetsya v osnovnom dlya ogranichennyh po vremeni, reklamnyh
servisov i dlya resursov, prinadlezhashchih lichnostyam, bol'she ne
zanimayushchimsya sajtom. Ne obyazatel'no otmechat' vse postoyanno
nedostupnye resursy kak "udalennye" ("gone") ili hranit' zapis' v
techenie lyubogo otrezka vremeni - eto predostavlyaetsya na usmotrenie
vladel'ca servera.
10.4.12 411 Trebuetsya dlina, Length Required.
Server otkazyvaetsya prinimat' zapros s neopredelennym
Content-Length. Klient MOZHET povtorit' zapros, esli dobavit
dopustimoe pole zagolovka Content-Length, soderzhashchee dlinu tela
soobshcheniya (message-body) v soobshchenii zaprosa.
10.4.13 412 Preduslovie neverno, Precondition Failed.
Preduslovie, predstavlennoe odnim ili neskol'kimi polyami zagolovka
zaprosa (request-header), okazalos' lozhnym pri proverke serverom.
|tot kod otveta pozvolyaet klientu pomestit' predusloviya na tekushchuyu
metainformaciyu resursa (dannye polej zagolovka) i, takim obrazom,
predotvratit' primenenie zaproshennogo metoda k resursu, otlichnomu
ot togo, dlya kotorogo prednaznachen metod.
10.4.14 413 Ob容kt zaprosa slishkom bol'shoj, Request Entity Too Large.
Server otkazyvaetsya obrabatyvat' zapros, potomu chto ob容kt zaprosa
bol'she, chem server zhelaet ili sposoben obrabotat'. Server mozhet
zakryt' soedinenie, chtoby ne dat' klientu vozmozhnost' prodolzhit'
zapros.
Esli eto vremennoe sostoyanie, to serveru SLEDUET vklyuchit' pole
zagolovka Retry-After dlya ukazaniya vremeni, cherez kotoroe klient
mozhet snova povtorit' zapros.
10.4.15 414 URI zaprosa slishkom dlinnyj, Request-URI Too Long.
Server otkazyvaetsya obsluzhivat' zapros, potomu chto zaprashivaemyj
URI (Request-URI) dlinnee, chem server zhelaet interpretirovat'. |to
redkoe sostoyanie, kotoroe, po vsej veroyatnosti, proishodit tol'ko
togda, kogda klient nepravil'no preobrazoval zapros POST k zaprosu
GET s dlinnoj informaciej zaprosa, libo kogda klient popal v
"chernuyu dyru" URL perenapravleniya (naprimer, perenapravlennyj URL
prefiks ukazyvaet na svoj suffiks), ili kogda na server
proizvoditsya napadenie klientom, pytayushchimsya ekspluatirovat'
lazejki v sekretnosti, imeyushchiesya v nekotoryh serverah,
ispol'zuyushchih bufera fiksirovannoj dliny dlya chteniya ili
manipulirovaniya s zaprashivaemym URI (Request-URI).
10.4.16 415 Nepodderzhivaemyj media tip, Unsupported Media Type.
Server otkazyvaetsya obsluzhivat' zapros, potomu chto ob容kt zaprosa
nahoditsya v formate, ne podderzhivaemom zaproshennym resursom dlya
zaproshennogo metoda.
10.5 5xx - Kody oshibok servera.
Kody sostoyaniya, nachinayushchiesya s cifry "5" ukazyvayut sluchai, v
kotoryh server znaet, chto dopustil oshibku ili nesposoben vypolnit'
zapros. Otvechaya na zapros, za isklyucheniem zaprosa HEAD, serveru
SLEDUET vklyuchit' ob容kt, soderzhashchij ob座asnenie oshibochnoj situacii
i informaciyu, yavlyaetsya li eto polozhenie vremennym ili postoyannym.
Agentam pol'zovatelya SLEDUET pokazyvat' pol'zovatelyu lyuboj
vklyuchennyj ob容kt. |ti kody sostoyaniya primenimy k lyubomu metodu
zaprosa.
10.5.1 500 Vnutrennyaya oshibka servera, Internal Server Error.
Server stolknulsya s nepredvidennym usloviem, kotoroe ne pozvolyaet
emu vypolnit' zapros.
10.5.2 501 Ne realizovano, Not Implemented.
Server ne podderzhivaet funkcional'nye vozmozhnosti, trebuemye dlya
vypolneniya zaprosa. |tot otvet sootvetstvuet sostoyaniyu, kogda
server ne raspoznaet metod zaprosa i ne sposoben obespechiti' ego
dlya lyubogo resursa.
10.5.3 502 Oshibka shlyuza, Bad Gateway.
Server, dejstvuya v kachestve shlyuza ili proksi-servera, poluchil
nedopustimyj otvet ot sleduyushchego servera v cepochke zaprosov, k
kotoromu obratilsya pri popytke vypolnit' zapros.
10.5.4 503 Servis nedostupen, Service Unavailable.
Server v nastoyashchee vremya ne sposoben obrabotat' zapros iz-za
vremennoj peregruzki ili obsluzhivaniya servera. |to vremennoe
uslovie, kotoroe budet oblegcheno posle nekotoroj zaderzhki.
Esli izvestna prodolzhitel'nost' zaderzhki, ona mozhet byt' ukazana
v zagolovke Retry-After. Esli Retry-After ne prisutstvuet v
otvete, klientu SLEDUET obrabatyvat' etot otvet kak otvet s kodom
500.
Obratite vnimanie: sushchestvovanie koda sostoyaniya 503 ne
podrazumevaet, chto server dolzhen ispol'zovat' ego, kogda
peregruzhen. Nekotorye servera mogut prosto zakryvat' soedinenie.
10.5.5 504 Isteklo vremya ozhidaniya ot shlyuza, Gateway Timeout.
Server, dejstvuya v kachestve shlyuza ili proksi-servera, ne poluchil
svoevremennogo otveta ot sleduyushchego servera v cepochke zaprosov, k
kotoromu obratilsya pri popytke vypolnit' zapros.
10.5.6 505 Ne podderzhivaemaya versiya HTTP, HTTP Version Not Supported.
Server ne podderzhivaet, ili otkazyvaetsya podderzhivat', versiyu HTTP
protokola, kotoraya ispol'zuetsya v soobshchenii zaprosa. Server
ukazyvaet, chto ne sposoben ili ne zhelaet vypolnyat' zapros,
ispol'zuya tu zhe samuyu major versiyu, chto i klient, kak opisano v
razdele 3.1, v drugih soobshcheniyah. Otvetu SLEDUET soderzhat' ob容kt,
opisyvayushchij, pochemu eta versiya ne podderzhivaetsya, i kakie drugie
protokoly podderzhivayutsya etim serverom.
11 Ustanovlenie podlinnosti dostupa (Access Authentication).
HTTP obespechivaet dlya ustanovleniya podlinnosti prostoj mehanizm
vyzov-otvet (challenge-response), kotoryj MOZHET ispol'zovat'sya
serverom dlya vyzova (challenge) klientskogo zaprosa, a klientom
dlya predostavleniya opoznavatel'noj informacii (authentication
information). On ispol'zuet rasshiryaemuyu, ne chuvstvitel'nuyu k
registru leksemu identifikacii shemy ustanovleniya podlinnosti
(authentication scheme) i otdelennyj zapyatoj spisok par
atribut-znachenie (attribute-value), kotorye predstavlyayut
parametry, neobhodimye dlya ustanovleniya podlinnosti s
ispol'zovaniem etoj shemy.
auth-scheme = token
auth-param = token "=" quoted-string
Soobshchenie otveta s kodom 401 (Nesankcionirovan, Unauthorized)
ispol'zuetsya pervonachal'nym serverom dlya vyzova (challenge)
ustanovleniya podlinnosti (authorization) agentom pol'zovatelya.
|tot otvet DOLZHEN soderzhat' pole zagolovka WWW-Authenticate,
vklyuchayushchee po krajnej mere odin vyzov (challenge), primenimyj k
zaproshennomu resursu.
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
Atribut oblasti (realm) (ne chuvstvitel'nyj k registru) trebuetsya
dlya vseh shem ustanovleniya podlinnosti, kotorye vydayut vyzov
(challenge). Znachenie attributa realm (chuvstvitel'noe k registru),
v kombinacii s kanonicheskim kornevym URL (smotret' razdel 5.1.2)
servera, k kotoromu obrashchen zapros, opredelyaet oblast' zashchity
(protection space). |ti oblasti pozvolyayut razbivat' zashchishchennye
resursy servera na mnozhestvo oblastej, kazhdaya iz kotoryh imeet
sobstvennuyu opoznavatel'nuyu shemu i/ili bazu dannyh ustanovleniya
podlinnosti (authorization database). Znachenie realm - stroka,
voobshche govorya naznachennaya pervonachal'nym serverom, kotoraya mozhet
imet' dopolnitel'nuyu semantiku, specificheskuyu dlya shemy
ustanovleniya podlinnosti (authentication scheme).
Agent pol'zovatelya, kotoryj hochet dokazat' svoyu podlinnost'
serveru, obychno, no ne obyazatel'no, MOZHET eto sdelat' posle
polucheniya otveta s kodom sostoyaniya 401 ili 411, vklyuchiv pole
zagolovka Authorization v zapros. Znachenie polya Authorization
sostoit iz rekomendacij (credentials), soderzhashchih informaciyu
ustanovleniya podlinnosti (authentication information) agenta
pol'zovatelya dlya oblasti (realm) zaproshennogo resursa.
credentials = basic-credentials
| auth-scheme #auth-param
Oblast' (domain), nad kotoroj rekomendacii (credentials) mogut
avtomaticheski primenyat'sya agentom pol'zovatelya, opredelena
oblast'yu zashchity (protection space). Esli podlinnost' byla
ustanovlena predshestvuyushchim zaprosom, to eti zhe rekomendacii
(credentials) MOGUT ispol'zovat'sya mnogokratno vo vseh drugih
zaprosah vnutri etoj oblasti zashchity (protection space) v techenii
vremeni, opredelennogo shemoj ustanovleniya podlinnosti,
parametrami, i/ili ustanovkami pol'zovatelya. Esli shemoj
ustanovleniya podlinnosti ne opredeleno inogo, to odinochnaya oblast'
zashchity (protection space) ne mozhet prostirat'sya shire oblasti
servera (the scope of its server).
Esli server ne zhelaet prinimat' rekomendacii (credentials),
poslannye v zaprose, to emu SLEDUET vozvratit' otvet s kodom 401
(Nesankcionirovan, Unauthorized). Otvet DOLZHEN vklyuchat' pole
zagolovka WWW-Authenticate, soderzhashchee (vozmozhno novyj) vyzov
(challenge), primenimyj k zaproshennomu resursu, i ob容kt,
ob座asnyayushchij otkaz.
Protokol HTTP ne ogranichivaet prilozheniya ispol'zovaniem etogo
prostogo mehanizma vyzov-otvet (challenge-response) dlya
ustanovleniya podlinnosti dostupa. MOZHNO ispol'zovat'
dopolnitel'nye mehanizmy, takie kak shifrovanie na transportnom
urovne ili formirovanie paketa soobshcheniya (message encapsulation)
s dopolnitel'nymi polyami zagolovka, opredelyayushchimi informaciyu
ustanovleniya podlinnosti. Odnako eti dopolnitel'nye mehanizmy ne
opredeleny v etoj specifikacii.
Proksi-servera DOLZHNY byt' polnost'yu prozrachny dlya ustanovleniya
podlinnosti agenta pol'zovatelya. To est' oni DOLZHNY peresylat'
zagolovki WWW-Authenticate i Authorization netronutymi i
sledovat' pravilam razdela 14.8.
HTTP/1.1 pozvolyaet klientu peredavat' informaciyu ustanovleniya
podlinnosti dlya i ot proksi-servera posredstvom zagolovkov
Proxy-Authenticate i Proxy-Authorization.
11.1 Bazovaya shema ustanovleniya podlinnosti (Basic Authentication
Scheme).
"Bazovaya" shema ustanovleniya podlinnosti osnovana na tom, chto
agent pol'zovatelya dolzhen dokazyvat' svoyu podlinnost' pri pomoshchi
identifikatora pol'zovatelya (user-ID) i parolya (password) dlya
kazhdoj oblasti (realm). Znacheniyu oblasti (realm) sleduet byt'
neprozrachnoj (opaque) strokoj, kotoruyu mozhno proveryat' tol'ko na
ravenstvo s drugimi oblastyami na etom servere. Server obsluzhit
zapros, tol'ko esli on mozhet proverit' pravil'nost' identifikatora
pol'zovatelya (user-ID) i parolya (password) dlya zashchishchennoj oblasti
(protection space) zaproshennogo URI (Request-URI). Nikakih
opcional'nyh opoznavatel'nyh parametrov net.
Posle polucheniya zaprosa na URI, nahodyashchijsya v zashchishchaemoj oblasti
(protection space), server MOZHET otvetit' vyzovom (challenge),
podobnym sleduyushchemu:
WWW-Authenticate: Basic realm="WallyWorld"
gde "WallyWorld" - stroka, naznachennaya serverom, kotoraya
identificiruet oblast' zashchity zaprashivaemogo URI (Request-URI).
CHtoby poluchit' prava dostupa, klient posylaet identifikator
pol'zovatelya (userid) i parol' (password), razdelennye odnim
simvolom dvoetochiya (":"), vnutri base64-kodirovannoj stroki
rekomendacij (credentials).
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64-kodirovannyj [7] user-pass,
za isklyucheniem ne ogranichennyh 76
simvolami v stroke>
user-pass = userid ":" password
userid = *<TEXT ne soderzhashchij ":">
password = *TEXT
Userid mozhet byt' chuvstvitelen k registru.
Esli agent pol'zovatelya hochet poslat' identifikator pol'zovatelya
(userid) "Aladdin", i parol' (password) "open sesame", on budet
ispol'zovat' sleduyushchee pole zagolovka:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Soglasheniya o zashchite, svyazannye s bazovoj shemoj ustanovleniya
podlinnosti, smotrite v razdele 15.
11.2 Obzornaya shema ustanovleniya podlinnosti (Digest Authentication
Scheme).
Obzornoe ustanovlenie podlinnosti dlya HTTP opredelyaetsya v
RFC 2069 [32].
12 Obsuzhdenie soderzhimogo (Content Negotiation).
Bol'shinstvo HTTP otvetov vklyuchayut ob容kt, kotoryj soderzhit
informaciyu, prednaznachennuyu dlya interpretacii pol'zovatelem.
Estestvenno zhelanie obespechit' pol'zovatelya "luchshim dostupnym"
ob容ktom, sootvetstvuyushchim zaprosu. K sozhaleniyu dlya serverov i
keshej, ne vse pol'zovateli imeyut odinnakovye predpochteniya, i ne
vse agenty pol'zovatelya odinakovo sposobny k vizualizacii vseh
tipov ob容ktov. Po etoj prichine, HTTP imeet sredstva dlya
neskol'kih mehanizmov "obsuzhdeniya soderzhimogo" - processa vybora
samogo luchshego predstavleniya dlya dannogo otveta, kogda dostupno
neskol'ko predstavlenij.
Obratite vnimanie: |to ne vyzyvaetsya "obsuzhdenie formata"
("format negotiation"), potomu chto al'ternativnye predstavleniya
mogut imet' odinnakovyj media tip, no ispol'zovat' razlichnye
vozmozhnosti etogo tipa, imet' raznye yazyki i t.d.
Lyuboj otvet, soderzhashchij telo ob容kta (entity-body) MOZHET byt'
temoj obsuzhdeniya, vklyuchaya oshibochnye otvety.
Imeyutsya dva vida obsuzhdeniya soderzhimogo, kotorye vozmozhny v HTTP:
upravlyaemoe serverom i upravlyaemoe agentom obsuzhdenie. |ti dva
vida obsuzhdeniya nezavisimy, i, takim obrazom, mogut ispol'zovat'sya
otdel'no ili vmeste. Odin metod ispol'zovaniya ih vmeste,
upominaemyj kak prozrachnoe obsuzhdenie, proishodit, kogda kesh
ispol'zuet informaciyu obsuzhdeniya, upravlyaemogo agentom,
predostavlyaya ee pervonachal'nomu serveru, dlya obespecheniya
upravlyaemogo serverom obsuzhdeniya pri posleduyushchih zaprosah.
12.1 Upravlyaemoe serverom obsuzhdenie.
Obsuzhdenie nazyvaetsya upravlyaemym serverom, esli vybor samogo
luchshego predstavleniya dlya otveta proizveden algoritmom,
razmeshchennym na servere. Vybor osnovan na dostupnyh predstavleniyah
otveta (oni mogut razlichat'sya po neskol'kim harakteristikam;
naprimer yazyku, kodirovaniyu soderzhimogo (content-coding), i t.d.)
i soderzhanii specificheskih polej zagolovka v soobshchenii zaprosa,
ili na drugoj informacii, imeyushchej otnoshenie k zaprosu (takoj kak
setevoj adres klienta).
Upravlyaemoe serverom obsuzhdenie vygodno, kogda algoritm vybora iz
chisla dostupnyh predstavlenij trudno opisat' agentu pol'zovatelya,
ili kogda server zhelaet poslat' "luchshee predpolozhenie" klientu
odnovremenno s pervym otvetom (nadeyas' izbezhat' zaderzhki peresylki
tuda i obratno posleduyushchego zaprosa, esli "luchshee predpolozhenie"
ustroit pol'zovatelya). CHtoby uluchshit' predpolozhenie servera,
agent pol'zovatelya MOZHET vklyuchat' polya zagolovka zaprosa (Accept,
Accept-Language, Accept-Encoding, i t.d.), kotorye opisyvayut
predpochtitel'nyj otvet.
Upravlyaemoe serverom obsuzhdenie imeet nedostatki:
1. Server ne mozhet tochno opredelit', chto moglo by byt' "samym
luchshim" dlya dannogo pol'zovatelya, tak kak eto trebuet polnogo
znaniya, kak vozmozhnostej agenta pol'zovatelya, tak i celej
ispol'zovaniya otveta (naprimer, pol'zovatel' hochet
prosmatrivat' ego na ekrane ili pechatat' na bumage?).
2. Nalichie opisaniya vozmozhnostej agenta pol'zovatelya v kazhdom
zaprose mozhet byt' ochen' neeffektivnym (pri uslovii, chto
tol'ko nebol'shoj procent otvetov imeet neskol'ko
predstavlenij) i potencial'no narushaet sekretnost'
pol'zovatelya.
3. Ono uslozhnyaet realizaciyu pervonachal'nogo servera i algoritmov
generacii otvetov na zapros.
4. Ono mozhet ogranichivat' sposobnost' obshchego kesha ispol'zovat'
odin i tot zhe otvet dlya zaprosov neskol'kih pol'zovatelej.
HTTP/1.1 vklyuchaet sleduyushchie polya zagolovka zaprosa
(request-header), kotorye obespechivayut upravlyaemoe serverom
obsuzhdenie posredstvom opisaniya vozmozhnostej agenta pol'zovatelya
i predpochtenij samogo pol'zovatelya: Accept (razdel 14.1),
Accept-Charset (razdel 14.2), Accept-Encoding (razdel 14.3),
Accept-Language (razdel 14.4), and User-Agent (razdel 14.42).
Odnako pervonachal'nyj server ne ogranichen etim i MOZHET izmenit'
otvet, osnovyvayas' na lyubom aspekte zaprosa, vklyuchaya informaciyu,
kotoraya ne soderzhitsya v polyah zagolovka zaprosa ili informaciyu iz
rasshirennyh polej zagolovka, ne opredelennyh v etoj specifikacii.
Pervonachal'nyj server HTTP/1.1 DOLZHEN vklyuchat' sootvetstvuyushchee
pole zagolovka Vary (razdel 14.43) v lyuboj keshiruemyj otvet,
osnovannyj na upravlyamom serverom obsuzhdenii. Pole zagolovka Vary
opisyvaet harakteristiki, kotorye mogut menyat'sya v otvete (to est'
harakteristiki, soglasno kotorym pervonachal'nyj server vybiraet
"nailuchshij" otvet iz neskol'kih predstavlenij).
Obshchie HTTP/1.1 keshi DOLZHNY raspoznat' pole zagolovka Vary, esli
on prisutstvuet v otvete, i otvechat' trebovaniyam, opisannym v
razdele 13.6, kotoryj opisyvaet vzaimodejstviya mezhdu keshirovaniem
i obsuzhdeniem soderzhimogo.
12.2 Upravlyaemoe agentom obsuzhdenie.
Pri upravlyaemom agentom obsuzhdenii, vybor luchshego predstavleniya
otveta vypolnyaetsya agentom pol'zovatelya posle polucheniya nachal'nogo
otveta pervonachal'nogo servera. Vybor osnovan na spiske dostupnyh
predstavlenij otveta, vklyuchennom v polya zagolovka (eta
specifikaciya rezerviruet imya polya Alternates, kak opisano v
prilozhenii 19.6.2.1) ili telo ob容kta nachal'nogo otveta. Kazhdoe
predstavlenie identificiruetsya sobstvennym URI. Vybor
predstavleniya mozhet vypolnyat'sya avtomaticheski (esli agent
pol'zovatelya sposoben eto sdelat') ili vruchnuyu pol'zovatelem iz
sgenerirovannogo (vozmozhno gipertekstovogo) menyu.
Upravlyaemoe agentom obsuzhdenie vygodno, kogda otvet var'iruetsya po
obshcheispol'zuemym harakteristikam (takim kak tip, yazyk, ili
kodirovanie), kogda pervonachal'nyj server ne sposoben opredelit'
vozmozhnosti agenta pol'zovatelya putem issledovaniya zaprosa, i
obychno pri ispol'zovanii obshchih keshej dlya raspredeleniya nagruzki
na server i umen'sheniya ispol'zovaniya seti.
Upravlyaemoe agentom obsuzhdenie stradaet tem, chto dlya polucheniya
samogo luchshego al'ternativnogo predstavleniya trebuetsya vtoroj
zapros. |tot vtoroj zapros effektiven tol'ko togda, kogda
ispol'zuetsya keshirovanie. Krome togo, eta specifikaciya ne
opredelyaet nikakogo mehanizma dlya obespecheniya avtomaticheskogo
vybora, hotya takzhe i ne predotvrashchaet razrabotku takogo mehanizma
v kachestve rasshireniya i ispol'zovaniya v HTTP/1.1.
HTTP/1.1 opredelyaet kody sostoyaniya 300 (Mnozhestvennyj vybor,
Multiple Choices) i 406 (Ne priemlem, Not Acceptable) dlya
obespecheniya upravlyaemogo agentom obsuzhdeniya, kogda server ne
zhelaet ili ne sposoben obespechit' izmenenie otveta, ispol'zuya
upravlyaemoe serverom obsuzhdenie.
12.3 Prozrachnoe obsuzhdenie.
Prozrachnoe obsuzhdenie - eto kombinaciya upravlyaemogo serverom i
upravlyaemogo agentom obsuzhdeniya. Kogda kesh obespechen spiskom
dostupnyh predstavlenij otveta (kak pri upravlyaemom agentom
obsuzhdenii) i izmenyayushchiesya harakteristiki polnost'yu ponyaty keshem,
togda on sposoben vypolnyat' upravlyaemoe serverom obsuzhdenie
posleduyushchih zaprosov etogo zhe resursa ot imeni pervonachal'nogo
servera.
Prozrachnoe obsuzhdenie imeet to preimushchestvo, chto rabota po
obsuzhdeniyu raspredelyaetsya. Kogda kesh sposoben pravil'no
predpolozhit' nuzhnyj otvet sokrashchaetsya rabota, kotoraya ran'she
trebovalas' ot pervonachal'nogo servera i ne proishodit zaderzhki
vtorogo zaprosa, kak pri upravlyaemom agentom obsuzhdenii.
|ta specifikaciya ne opredelyaet nikakogo mehanizma prozrachnogo
obsuzhdeniya, hotya takzhe i ne predotvrashchaet razrabotku takogo
mehanizma v kachestve rasshireniya i ispol'zovaniya v HTTP/1.1.
HTTP/1.1 kesh, vypolnyayushchij prozrachnoe obsuzhdenie DOLZHEN vklyuchat'
pole zagolovka Vary (opredelyayushchee parametry, kotorye mogut
var'irovat'sya) v otvet, esli on keshiruem, chtoby garantirovat'
pravil'nuyu interpretaciyu vsemi HTTP/1.1 klientami. Informaciyu
upravlyaemogo agentom obsuzhdeniya, predstavlennuyu pervonachal'nym
serverom, SLEDUET vklyuchat' v otvet pri prozrachnom obsuzhdenii.
Last-modified: Thu, 03 Dec 1998 18:04:08 GMT