nazad | soderzhanie | vpered

5 Zapros (Request).

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

5.1.1 Metod (Method).

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®ekta (entity-header).


Copyright  ©  1998 Alex Simonoff (http://www.omsk.com/Leshik/), All Rights Reserved.


nazad | soderzhanie | vpered