3 Џараметры протокола.

3.1 ‚ерсиЯ HTTP.

HTTP использует схему нумерации типа "<major>.<minor>", длЯ указаниЯ версии протокола. ‘тратегиЯ версификации протокола предназначена длЯ того, чтобы позволить отправителю указать формат сообщениЯ и свои способности пониманиЯ длЯ дальнейшей HTTP свЯзи, прежде чем он получит что-либо посредством этой свЯзи. Џри добавлении компонентов сообщениЯ, которые не воздействуют на поведение свЯзи, или компонентов, которые добавлЯютсЯ только к расширЯемым значениЯм полЯ, номер версии не менЯетсЯ. Љогда внесенные в протокол изменениЯ добавлЯют возможности, которые не изменЯют общий алгоритм анализа сообщений, но которые расширЯют семантику сообщениЯ и подразумевают дополнительные возможности отправителЯ, увеличиваетсЯ <Minor> номер. Љогда формат сообщениЯ протокола изменЯетсЯ увеличиваетсЯ <Major> номер.

‚ерсиЯ HTTP сообщениЯ обозначаетсЯ полем HTTP-version в первой строке сообщениЯ.

          HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Ћбратите внимание, что major и minor числа „Ћ‹†Ќ› обрабатыватьсЯ как отдельные целые числа и что каждое может состоЯть более чем из одной цифры. ’аким образом, HTTP/2.4 - более низкаЯ версиЯ, чем HTTP/2.13, котораЯ в свою очередь ниже чем HTTP/12.3. Ќули „Ћ‹†Ќ› игнорироватьсЯ получателЯми и Ќ… „Ћ‹†Ќ› посылатьсЯ.

ЏриложениЯ, посылающие сообщениЯ запросов или ответов, которые описывает эта спецификациЯ, „Ћ‹†Ќ› включить HTTP версию (HTTP-version) "HTTP/1.1". €спользование этого номера версии указывает, что посылающее приложение по крайней мере условно совместимо с этой спецификацией.

HTTP версиЯ приложениЯ - это самаЯ высокаЯ HTTP версиЯ, длЯ которой приложение ЯвлЯетсЯ по крайней мере условно совместимым.

ЏриложениЯ, реализующие прокси-сервера и шлюзы, должны быть внимательны, когда пересылают сообщениЯ протокола различных версий. ЌачинаЯ с момента, когда версиЯ протокола указывает возможности отправителЯ, прокси-сервер/шлюз никогда Ќ… „Ћ‹†…Ќ посылать сообщениЯ, версиЯ которых больше, чем HTTP версиЯ отправителЯ; если получена более высокаЯ версиЯ запроса, то прокси-сервер/шлюз „Ћ‹†…Ќ или понизить версию запроса, отдав сообщение об ошибке, или переключитьсЯ на туннельное поведение. “ запросов, версиЯ которых ниже, чем HTTP версиЯ прокси-сервера/шлюза ЊЋ†ЌЋ перед пересылкой увеличить версию; ответ прокси-сервера/шлюза на этот запрос „Ћ‹†…Ќ иметь ту же самую major версию, что и запрос.

Ћбратите внимание: Џреобразование версий HTTP может включать модификацию полей заголовка, требуемых или запрещенных в этих версиЯх.

3.2 “ниверсальные €дентификаторы ђесурсов (URI).

URI известны под многими именами: WWW адреса, “ниверсальные €дентификаторы „окументов, “ниверсальные €дентификаторы ђесурсов (URI), и, в заключение, как комбинациЯ …динообразных €дентификаторов ђесурса (Uniform Resource Locators, URL) и …динообразных €мен ђесурса (Uniform Resource Names, URN). HTTP определЯет URL просто как строку определенного формата, котораЯ идентифицирует - через имЯ, расположение, или любую другую характеристику - ресурс.

3.2.1 Ћбщий синтаксис.

URI в HTTP могут представлЯтьсЯ в абсолютной (absolute) форме или относительно некоторой известной основы URI (relative), в зависимости от контекста их использованиЯ. ќти две формы различаютсЯ тем, что абсолютные URI всегда начинаютсЯ с имени схемы с двоеточием.

          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    = <любой OCTET за исключением ALPHA, DIGIT,
                           reserved, extra, safe, и unsafe>

Џолную информацию относительно синтаксиса и семантики URL смотрите RFC 1738 [4] € RFC 1808 [11]. ‚ышеуказаннаЯ нормальнаЯ запись Ѓекуса-Ќаура включает национальные символы, недозволенные в допустимых URL (это определено в RFC 1738), так как HTTP серверы позволЯют использовать длЯ представлениЯ части rel_path адресов набор незарезервированных символов, и, следовательно, HTTP прокси-сервера могут получать запросы URI, не соответствующие RFC 1738.

Џротокол HTTP не накладывает a priori никаких ограничений на длины URI. ‘ерверы „Ћ‹†Ќ› быть способны обработать URI любого ресурса, который они обслуживают, и им ‘‹…„“…’ быть в состоЯнии обрабатывать URI неограниченной длины, если они обслуживают формы, основанные на методе GET, которые могут генерировать такой URI. ‘ерверу ‘‹…„“…’ возвращать код состоЯниЯ 414 (URI запроса слишком длинный, Request-URI Too Long), если URI больше, чем сервер может обработать (смотрите раздел 10.4.15).

Ћбратите внимание: ‘ерверы должны быть осторожны с URI, которые имеют длину более 255 байтов, потому что некоторые старые клиенты или прокси-сервера не могут правильно поддерживать эти длины.

3.2.2 HTTP URL.

"Http" схема используетсЯ длЯ доступа к сетевым ресурсам при помощи протокола HTTP. ќтот раздел определЯет схемо-определенный синтаксис и семантику длЯ HTTP URL.

          http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

          host           = <допустимое доменное имЯ машины
                            или IP адрес (в точечно-десЯтичной форме),
                            как определено в разделе 2.1 RFC 1123>

          port           = *DIGIT

…сли порт пуст или не задан - используетсЯ порт 80. ќто означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса - abs_path. €спользованиЯ IP адресов в URL ‘‹…„“…’ избегать, когда это возможно (смотрите RFC 1900 [24]). …сли abs_path не представлен в URL, он „Ћ‹†…Ќ рассматриватьсЯ как "/" при вычислении запрашиваемого URI (Request-URI) ресурса (раздел 5.1.2).

3.2.3 ‘равнение URI.

Џри сравнении двух URI, чтобы решить соответствуют ли они друг другу или нет, клиенту ‘‹…„“…’ использовать чувствительное к регистру пооктетное (octet-by-octet) сравнение этих URI, со следующими исключениЯми:

Џорт, который пуст или не указан, эквивалентен заданному по умолчанию порту длЯ этого URI;
‘равнение имен хостов „Ћ‹†ЌЋ производитьсЯ без учета регистра;
‘равнение имен схем „Ћ‹†ЌЋ производитьсЯ без учета регистра;
Џустой abs_path эквивалентен "/".

‘имволы, отличные от тех, что находЯтсЯ в "зарезервированных" ("reserved") и "опасных" ("unsafe") наборах (см. раздел 3.2) эквивалентны их кодированию как ""%" HEX HEX ".

Ќапример следующие три URI эквивалентны:

         http://abc.com:80/~smith/home.html
         http://ABC.com/%7Esmith/home.html
         http://ABC.com:/%7esmith/home.html

3.3 ”орматы даты/времени.

3.3.1 ЏолнаЯ дата.

HTTP приложениЯ исторически допускали три различных формата длЯ представлениЯ даты/времени:

      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, дополненный в RFC 1123
      Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, переписанный как RFC 1036
      Sun Nov  6 08:49:37 1994       ; формат asctime() ANSI C

Џервый формат выбран в качестве стандарта €нтернета и представлЯет подмножество фиксированной длины, как определено в RFC 1123 (модифицированном RFC 822). ‚торой формат находитсЯ в общем пользовании, но основан на устаревшем и потерЯвшем статус стандарта RFC 850 [12], описывающем форматы дат, он обладает тем недостатком, что год указываетсЯ не в четырехразрЯдной нотации. Љлиенты и серверы HTTP/1.1, которые анализируют значение даты, „Ћ‹†Ќ› понимать все три формата (длЯ совместимости с HTTP/1.0), но генерировать длЯ представлениЯ значений дат в полЯх заголовка HTTP „Ћ‹†Ќ› только формат RFC 1123 .

Ћбратите внимание: ЏоощрЯетсЯ практика, при которой получатели значений дат здраво воспринимают значениЯ дат, которые, возможно, посланы не HTTP приложениЯми, что имеет место при загрузке или регистрации сообщений через прокси-сервера/шлюзы к SMTP или NNTP.

‚се без исключений форматы HTTP даты/времени „Ћ‹†Ќ› быть представлены в Greenwich Mean Time (GMT). ‚ первых двух форматах данный факт указываетсЯ включением трехсимвольного сокращениЯ "GMT" в качестве часового поЯса. ‚ asctime() формате это „Ћ‹†ЌЋ подразумеватьсЯ при чтении.

          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
                         ; день месЯц год (например 02 Jun 1982)

          date2        = 2DIGIT "-" month "-" 2DIGIT
                         ; день-месЯц-год (напрмер 02-Jun-82)

          date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                         ; месЯц день (например, 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"

Ћбратите внимание: ќти требованиЯ - это требованиЯ к длЯ форматам даты/времени, которые применЯютсЯ внутри потока протокола HTTP. Љлиентам и серверам не требуетсЯ использовать эти форматы длЯ представлениЯ пользователю, регистрации запросов и т.д.

3.3.2 ђазность секунд (delta seconds).

Ќекоторые полЯ HTTP заголовка позволЯют указывать значениЯ времени в виде целого числа секунд, представленного в десЯтичной форме, которые должны пройти с того момента, как сообщение было получено.

          delta-seconds  = 1*DIGIT

3.4 Љодовые таблицы (character sets).

HTTP использует то же самое определение термина "кодоваЯ таблица", которое описано длЯ MIME:

’ермин "кодоваЯ таблица" используетсЯ в данном документе, чтобы сослатьсЯ на метод, использующий одну или несколько таблиц длЯ преобразованиЯ последовательности октетов в последовательность символов. ‘тоит отметить, что однозначное преобразование в обратном направлении не требуетсЯ, и что не все символы могут быть доступны в данной кодовой таблице, и что кодоваЯ таблица может обеспечивать более чем одну последовательность октетов длЯ представлениЯ специфических символов. ќто определение допускает различные виды кодированиЯ символов, от простых однотабличных отображений типа US-ASCII до сложных методов, переключающих таблицы, наподобие тех, которые используют методики ISO 2022. Ћднако определение, свЯзанное с именем кодовой таблицы MIME „Ћ‹†ЌЋ полностью определЯть отображение, которое преобразует октеты в символы. ‚ частности использование внешней информации профилированиЯ длЯ определениЯ точного отображениЯ не разрешаетсЯ.

Ћбратите внимание: ќто использование термина "кодоваЯ таблица" обычно упоминаетсЯ как "кодирование символов". Ћднако, с тех пор как HTTP и MIME совместно используют одиннаковую запись, важно, чтобы совпадала также и терминологиЯ.

Љодовые таблицы HTTP идентифицируютсЯ лексемами, не чувствительными к регистру. Џолный набор лексем определен реестром кодовых таблиц IANA [19].

          charset = token

•отЯ HTTP позволЯет использовать в качестве значениЯ charset произвольную лексему, любаЯ лексема, котораЯ имеет предопределенное значение в реестре кодовых таблиц IANA, „Ћ‹†ЌЂ представлЯть набор символов, определенный в данном реестре. ЏриложениЯм ‘‹…„“…’ ограничить использование символьных наборов теми, которые определены в реестре IANA.

3.5 Љодирование содержимого (content codings).

‡начение кодированиЯ содержимого указывает какое преобразование кодированиЯ было или будет применено к объекту. Љодирование содержимого используетсЯ прежде всего длЯ сжатиЯ или другого полезного преобразованиЯ к документу без потери идентификации основного медиа типа и информации. —асто, объект сохранЯетсЯ в кодированной форме, затем передаетсЯ, а потом декодируетсЯ получателем.

          content-coding   = token

‚се значениЯ кодированиЯ содержимого (content-coding) не чувствительны к регистру. HTTP/1.1 использует значениЯ кодированиЯ содержимого (content-coding) в полЯх заголовка Accept-Encoding (раздел 14.3) и Content-Encoding (раздел 14.12). •отЯ значение описывает кодирование содержимого, но, что более важно - оно указывает, какой механизм декодированиЯ потребуетсЯ длЯ обратного процесса.

Internet Assigned Numbers Authority (IANA) действует как реестр длЯ значений лексем кодированиЯ содержимого (content-coding). Џервоначально реестр содержал следующие лексемы:

gzip: ”ормат кодированиЯ, производЯщий сжатие файла программой "gzip" (GNU zip), как описано в RFC 1952 [25]. ќто формат Lempel-Ziv кодированиЯ (LZ77) с 32 разрЯдным CRC.
compress: ”ормат кодированиЯ, производимый общей программой "compress" длЯ сжатиЯ UNIX файлов. ќто формат адаптивного Lempel-Ziv-Welch кодированиЯ (LZW).
deflate: ”ормат zlib, определенный в RFC 1950 [31], в комбинации с механизмом сжатиЯ "deflate", описанным в RFC 1951 [29].

ЌоваЯ лексема значениЯ кодированиЯ содержимого (content-coding) должна быть зарегистрирована; чтобы обеспечить взаимодействие между клиентами и серверами, спецификациЯ алгоритма кодированиЯ содержимого, необходимого длЯ определениЯ нового значениЯ, должна быть открыто опубликована и адекватна длЯ независимой реализации, а также соответствовать цели кодированиЯ содержимого определенного в этом разделе.

3.6 Љодирование передачи (Transfer Codings).

‡начениЯ кодированиЯ передачи используютсЯ длЯ указаниЯ преобразованиЯ кодированиЯ, которое было или должно быть применено к телу объекта (entity-body) в целЯх гарантированиЯ "безопасной передачи" по сети. Ћно отличаетсЯ от кодированиЯ содержимого тем, что кодирование передачи - это свойство сообщениЯ, а не первоначального объекта.

          transfer-coding         = "chunked" | transfer-extension

          transfer-extension      = token

‚се значениЯ кодированиЯ передачи (transfer-coding) не чувствительны к регистру. HTTP/1.1 использует значениЯ кодированиЯ передачи (transfer-coding) в поле заголовка Transfer-Encoding (раздел 14.40).

ЉодированиЯ передачи - это аналоги значений Content-Transfer-Encoding MIME, которые были разработаны длЯ обеспечениЯ безопасной передачи двоичных данных при использовании 7-битного обслуживаниЯ передачи. Ћднако безопасный транспорт имеет другое предназначение длЯ чисто 8-битного протокола передачи. ‚ HTTP единственаЯ опаснаЯ характеристика тела сообщениЯ вызвана сложностью определениЯ точной длины тела сообщениЯ (раздел 7.2.2), или желанием шифровать данные при пользовании общедоступным транспортом.

Љодирование по кускам (chunked encoding) изменЯет тело сообщениЯ длЯ передачи его последовательностью кусков, каждый из которых имеет собственный индикатор размера, сопровождаемым опциональным завершителем, содержащим полЯ заголовка объекта. ќто позволЯет динамически создаваемому содержимому передаватьсЯ вместе с информацией, необходимой получателю длЯ проверки полноты получениЯ сообщениЯ.

       Chunked-Body   = *chunk
                        "0" CRLF
                        footer
                        CRLF

       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       hex-no-zero    = <HEX за исключением "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

Љодирование по кускам (chunked encoding) оканчиваетсЯ куском нулевого размера, следующим за завершителем, оканчивающимсЯ пустой строкой. –ель завершителЯ состоит в эффективном методе обеспечениЯ информации об объекте, который сгенерирован динамически; приложениЯ Ќ… „Ћ‹†Ќ› посылать в завершителе полЯ заголовка, которые Явно не предназначены длЯ использованиЯ в завершителе, такие как Content-MD5 или будущие расширениЯ HTTP длЯ цифровых подписей и других возможностей.

Џримерный процесс декодированиЯ Chunked-Body представлен в приложении 19.4.6.

‚се HTTP/1.1 приложениЯ „Ћ‹†Ќ› быть в состоЯнии получать и декодировать кодирование передачи "по кускам" ("chunked" transfer coding), и „Ћ‹†Ќ› игнорировать расширениЯ кодированиЯ передачи, которые они не понимают. ‘ерверу, который получил тело объекта со значением кодированиЯ передачи, которое он не понимает, ‘‹…„“…’ возвратить ответ с кодом 501 (Ќе реализовано, Not Implemented) и разорвать соединение. ‘ервер Ќ… „Ћ‹†…Ќ посылать полЯ кодированиЯ передачи (transfer-coding) HTTP/1.0 клиентам.

3.7 Њедиа типы (Media Types).

HTTP использует Њедиа ’ипы €нтернета (Internet Media Types) в полЯх заголовка Content-Type (раздел 14.18) и Accept (раздел 14.1) длЯ обеспечениЯ открытой и расширЯемой типизации данных и обсуждениЯ типов.

          media-type     = type "/" subtype *( ";" parameter )
          type           = token
          subtype        = token

Џараметры могут следовать за type/subtype в форме пар атрибут/значение (attribute/value).

          parameter      = attribute "=" value
          attribute      = token
          value          = token | quoted-string

’ип, подтип, и имена атрибутов и параметров не чувствительны к регистру. ‡начениЯ параметров могут быть чувствительными к регистру, но могут быть и не чувствительны, в зависимости от семантики имени параметра. ‹инейный пробел (LWS) Ќ… „Ћ‹†…Ќ использоватьсЯ между типом и подтипом, между атрибутом и значением. Ђгенты пользователей, распознающие медиа типы, „Ћ‹†Ќ› обрабатывать (или подготавливать длЯ обработки любыми внешними приложениЯми) параметры длЯ тех типов MIME, которые описаны, и сообщать пользователю о обнаруженных проблемах.

Ћбратите внимание: Ќекоторые старые HTTP приложениЯ не распознают параметры медиа типов. Џри посылке данных к таким HTTP приложениЯм реализации должны использовать параметры медиа типов только когда это требуетсЯ по определению типа/подтипа.

‡начениЯ медиа-типов регистрируютсЯ Internet Assigned Number Authority (IANA). Џроцесс регистрации медиа типа определен в RFC 2048 [17]. €спользование не зарегистрированных медиа типов вводит в заблуждение.

3.7.1 ЉанонизациЯ и предопределенные значениЯ типа text.

Њедиа типы €нтернета зарегистрированы в канонической форме. ‚ообще, тело объекта, передаваемое HTTP сообщением, „Ћ‹†ЌЋ быть представлено в соответствующей каноническиой форме до передачи; исключение составлЯют типы "text", определЯемые в следующем абзаце.

‚ канонической форме медиа подтипы типа "text" используют CRLF в качестве метки конца строки. HTTP ослаблЯет это требование и позволЯет передавать текст размеченный таким образом, что еденичные CR или LF могут быть метками конца строки, правда это правило должно быть выполнено длЯ всего тела объекта (entity-body). HTTP приложениЯ „Ћ‹†Ќ› воспринимать CRLF, просто CR, и просто LF как представление конца строки в текстовых типах, переданных по HTTP. Љроме того, если текст представлЯетсЯ в кодовой таблице, котораЯ не использует октеты 13 и 10 длЯ CR и LF соответственно, что имеет место в некоторых многобайтовых кодовых таблицах, то HTTP позволЯет использовать любые последовательности октетов, определенные этим набором символов длЯ представлениЯ эквивалентов CR и LF в качестве кода конца строки. ќта гибкость в отношении концов строк применима только к текстовым типам в теле объекта; просто CR или просто LF Ќ… „Ћ‹†Ќ› заменЯть CRLF внутри любой управлЯющей структуры HTTP (типа полЯ заголовка и разделителей типа multipart).

…сли тело объекта кодируетсЯ при помощи Content-Encoding, то основные данные „Ћ‹†Ќ› быть в определенной выше форме до кодированиЯ.

Џараметр "charset" используетсЯ с некоторыми медиа типами длЯ указаниЯ кодовой таблицы (раздел 3.4), используемой длЯ представлениЯ данных. …сли параметр "charset" не указан отправителем, то при получении по HTTP медиа подтипы типа "text" имеют значение "charset", по умолчанию равное "ISO-8859-1". „анные в кодовых таблицах или их подмножествах, отличных от "ISO-8859-1" „Ћ‹†Ќ› быть помечены соответствующим значением "charset".

Ќекоторое программное обеспечение HTTP/1.0 интерпретировало заголовок Content-Type без параметра "charset" неправильно, как означающее "должен предположить получатель". Ћтправители, желающие предусмотреть такое поведение ЊЋѓ“’ включать параметр "charset" даже когда charset равен ISO-8859-1 и „Ћ‹†Ќ› сделать это, если известно, что это не запутает получателЯ.

Љ сожалению, некоторые старые HTTP/1.0 клиенты не работали правильно с определением параметра "charset". HTTP/1.1 получатели „Ћ‹†Ќ› отдавать приоритет метке "charset", поставленной отправителем; и те агенты пользователей, которые имеют возможность "предположить" charset „Ћ‹†Ќ› при первоначальном отображении документа использовать charset из полЯ content-type, если они поддерживают такой charset, а затем использовать собственные установки.

3.7.2 ’ипы Multipart.

MIME предусматривает рЯд типов "multipart" - формирующих пакет из одного или нескольких объектов внутри тела одного сообщениЯ. ‚се типы mulptipart используют общий синтаксис, определеный в MIME [7], и „Ћ‹†Ќ› содержать разделительный параметр частью значениЯ медиа типа. ’ело сообщениЯ - самостоЯтельный элемент протокола и, следовательно, „Ћ‹†ЌЋ использовать только ‘RLF длЯ представлениЯ концов строк между частЯми тела (body-parts). ‚ отличие от MIME, окончание любого multipart сообщениЯ „Ћ‹†ЌЋ быть пустым; HTTP приложениЯ Ќ… „Ћ‹†Ќ› передавать окончание (даже если первоначальный multipart содержит заключение).

‚ HTTP части тела (body-parts) типа multipart ЊЋѓ“’ содержать полЯ заголовка, которые ЯвлЯютсЯ значащими в примнении к этой части. Џоле заголовка Content-Location (раздел 14.15) ‘‹…„“…’ включать в часть тела (body-part) каждого включенного объекта, который может быть идентифицирован URL.

‚ообще говорЯ, HTTP агенту пользователЯ ‘‹…„“…’ следовать такому же или подобному поведению, которому следовал бы MIME агент пользователЯ после получениЯ типа multipart. …сли приложение получает незарегистрированный подтип multipart, оно „Ћ‹†ЌЋ обрабатывать его как подтип "multipart/mixed".

Ћбратите внимание: тип "multipart/form-data" был специально определен длЯ передачи данных формы, подходЯщих длЯ обработки методом запроса POST, что описано в RFC 1867 [15].

3.8 ‹ексемы программ (Product Tokens).

‹ексемы программ используютсЯ, чтобы обеспечить коммуникационным приложениЯм возможность идентифицировать себЯ названием и версией программного обеспечениЯ. Ѓольшинство полей, использующих лексемы программ также допускает перечисление подпрограмм, которые формируют значительную часть приложениЯ, и которые перечислЯютсЯ через пробел. ‚ соответствии с соглашением, подпрограммы перечислЯютсЯ в порЯдке их значениЯ длЯ идентификации приложениЯ.

          product         = token ["/" product-version]
          product-version = token

Џримеры:

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3
          Server: Apache/0.8.4

‹ексемы программ должны быть короткими и по сути - использование их длЯ рекламы или другой несущественной информации однозначно запрещено. •отЯ в лексеме product-version может встречатьсЯ любой символ, все же ее следует использовать только длЯ идентификатора версии (то есть, последовательным версиЯм одной и той же программы ‘‹…„“…’ иметь отличиЯ только в части product-version лексемы product.

3.9 Љачественные значениЯ (Quality Values).

Ћбсуждение содержимого HTTP (раздел 12) использует короткие числа "с плавающей точкой" длЯ указаниЯ относительной важности ("веса") различных оговоренных параметров. ‚ес - это нормализованое вещественное число в диапазоне от 0 до 1, где 0 - минимальное, а 1 - максимальное значение. HTTP/1.1 приложениЯ Ќ… „Ћ‹†Ќ› генерировать более трех цифр после десЯтичной точки. Џользовательским конфигурациЯм этих значений ‘‹…„“…’ также ограничиватьсЯ этим режимом.

          qvalue         = ( "0" [ "." 0*3DIGIT ] )
                         | ( "1" [ "." 0*3("0") ] )

"Љачественные значениЯ" - не корректное название, так как эти значениЯ просто представлЯют отношение снижениЯ производительности к желательному качеству.

3.10 Њетки Языков (Language Tags).

Њетка Языка идентифицирует естественный Язык: разговорный, письменный, или другой используемый людьми длЯ обмена информацмей с другими людьми. Њашинные Языки ЯвлЯютсЯ исключением. HTTP использует метки Языка внутри полей Accept-Language и Content-Language.

‘интаксис и запись HTTP меток Языка такие же, как определЯемые RFC 1766 [1]. ‚ резюме, метка Языка состоит из одной или нескольких частей: метка первичного Языка и, возможно пустой, рЯд подчиненных меток:

           language-tag  = primary-tag *( "-" subtag )

           primary-tag   = 1*8ALPHA
           subtag        = 1*8ALPHA

‚нутри метки не допустим пробел и все метки не чувствительны к регистру. Џространство имен меток Языка управлЯетсЯ IANA. Ќапример метки содержат:

          en, en-US, en-cockney, i-cherokee, x-pig-latin

‹юбаЯ двухсимвольнаЯ первичнаЯ метка ЯвлЯетсЯ меткой аббревеатуры Языка ISO 639, а любаЯ двухсимвольнаЯ подчиненнаЯ метка ЯвлЯетсЯ меткой кода страны ISO 3166. (Џоследние три метки из вышеперечисленных - не зарегистрированные метки; все, кроме последней - примеры меток, которые могли бы быть зарегистрированы в будущем.)

3.11 Њетки объектов (Entity Tags).

Њетки объектов используютсЯ длЯ сравнениЯ двух или более объектов от одного и того же запрошенного ресурса. HTTP/1.1 использует метки объекта в полЯх заголовка ETag (раздел 14.20), If-Match (раздел 14.25), If-None-Match (раздел 14.26), и If-Range (раздел 14.27). Ћпределение того, как они используютсЯ и сравниваютсЯ в качестве меток проверки кэша находитсЯ в разделе 13.3.3. Њетка объекта состоит из непрозрачной цитируемой строки (opaque quoted string), возможно предваренной индикатором слабости (weakness indicator).

         entity-tag = [ weak ] opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

"‘ильнаЯ метка объекта" ("strong entity tag") может быть разделена двумЯ объектами ресурса, только если они пооктетно эквивалентны.

"‘лабаЯ метка объекта" ("weak entity tag"), обозначЯемаЯ префиксом "W/", может быть разделена двумЯ объектами ресурса только если объекты эквивалентны и могли бы заменЯть друг друга без значительного изменениЯ в семантике. ‘лабаЯ метка объекта может использоватьсЯ только длЯ слабого сравнениЯ.

Њетка объекта „Ћ‹†ЌЂ быть уникальна среди всех версий всех объектов, свЯзанных с конкретным ресурсом. „анное значение метки объекта может использоватьсЯ длЯ объектов, полученных запросами различных URI без предположениЯ эквивалентности этих объектов.

3.12 …деницы измерениЯ диапазонов (Range Units).

HTTP/1.1 позволЯет клиенту запрашивать только часть объекта. HTTP/1.1 использует еденицы измерениЯ диапазонов в полЯх заголовка Range (раздел 14.36) и Content-Range (раздел 14.17). Ћбъект может быть разбит на части соответственно различным структурным модулЯм.

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

…динственаЯ еденица измерениЯ диапазонов, определеннаЯ в HTTP/1.1 - это "bytes". ђеализации HTTP/1.1 могут игнорировать диапазоны, определенные с использованием других едениц измерениЯ. HTTP/1.1 был разработан, чтобы допускать реализации приложений, которые не зависЯт от знаниЯ диапазонов.