3 Parametry protokola.
3.1 Versiya HTTP.
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.
3.2.2 HTTP URL.
"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).
3.2.3 Sravnenie URI.
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:
- Port, kotoryj pust ili ne ukazan, ekvivalenten zadannomu po umolchaniyu portu dlya etogo URI;
- Sravnenie imen hostov DOLZHNO proizvodit'sya bez ucheta registra;
- Sravnenie imen shem DOLZHNO proizvodit'sya bez ucheta registra;
- 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.
3.3.1 Polnaya data.
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).
- deflate
- Format zlib, opredelennyj v RFC 1950 [31], v kombinacii s mehanizmom szhatiya "deflate", opisannym v RFC 1951 [29].
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.
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.
3.7.2 Tipy Multipart.
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.