4 HTTP soobshchenie (HTTP Message).

4.1 Tipy soobshchenij.

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®ektov (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®ekta (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®ekta.

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®edinit' 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®edinennogo znacheniya polya, i, sledovatel'no, proksi-server NE DOLZHEN izmenyat' poryadok znachenij etogo polya pri peresylke.

4.3 Telo coobshcheniya.

Telo HTTP soobshcheniya (message-body), esli ono prisutstvuet, ispol'zuetsya dlya peredachi tela ob®ekta, svyazannogo s zaprosom ili otvetom. Telo soobshcheniya (message-body) otlichaetsya ot tela ob®ekta (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®ekta, 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®ekta (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®ekta (entity-header), zastavlyayushchie poverit' v prisutstvie ob®ekta. 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.

4.4 Dlina soobshcheniya.

Kogda telo soobshcheniya (message-body) prisutstvuet v soobshchenii, dlina etogo tela opredelyaetsya odnim iz sleduyushchih metodov (v poryadke starshinstva):

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®ekta (entity-header fields), predstavlennyh v soobshchenii.
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).
Esli pole zagolovka Content-Length (razdel 14.14) prisutstvuet, to ego znachenie predstavlyaet dlinu tela soobshcheniya (message-body) v bajtah.
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.
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®ekty, 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®ektu. |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®ekta (entity-header).