<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.13 (Ruby 3.1.2) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-binary-message-06" number="9292" submissionType="IETF" category="std" consensus="true"submissionType="IETF"tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" updates="" obsoletes="" version="3"> <!-- xml2rfc v2v3 conversion 3.13.0 --> <front> <title abbrev="Binary HTTP Messages">Binary Representation of HTTP Messages</title> <seriesInfoname="Internet-Draft" value="draft-ietf-httpbis-binary-message-06"/>name="RFC" value="9292"/> <author initials="M." surname="Thomson" fullname="Martin Thomson"> <organization>Mozilla</organization> <address> <email>mt@lowentropy.net</email> </address> </author> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> <address> <email>caw@heapingbits.net</email> </address> </author> <date year="2022"month="July" day="06"/> <area>ART</area> <workgroup>HTTP</workgroup>month="August"/> <area>art</area> <workgroup>httpbis</workgroup> <abstract> <t>This document defines a binary format for representing HTTP messages.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/"/>. </t> <t> Discussion of this document takes place on the HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>. Working Group information can be found at <eref target="https://httpwg.org/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/httpwg/http-extensions/labels/binary-messages"/>.</t> </note></front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>This document defines a simple format for representing an HTTP message(<xref target="HTTP"/>),<xref target="RFC9110"/>, either request or response. This allows for the encoding of HTTP messages that can be conveyed outside an HTTP protocol. This enables the transformation of entire messages, including the application of authenticated encryption.</t> <t>The design of this format is informed by the framing structure of HTTP/2(<xref target="H2"/>)<xref target="RFC9113"/> and HTTP/3(<xref target="H3"/>).<xref target="RFC9114"/>. Rules for constructing messages rely on the rules defined in HTTP/2, but the format itself is distinct; see <xref target="differences"/>.</t> <t>This format defines<tt>message/bhttp</tt>,<tt>"message/bhttp"</tt>, a binary alternative to the<tt>message/http</tt><tt>"message/http"</tt> content type defined in <xreftarget="MESSAGING"/>.target="RFC9112"/>. A binary format permits more efficient encoding and processing of messages. A binary format also reduces exposure to security problems related to processing of HTTP messages.</t> <t>Two modes for encoding are described:</t> <ul spacing="normal"> <li>a known-length encoding includes length prefixes for all major messagecomponents;components, and</li> <li>an indeterminate-length encoding enables efficient generation of messages where lengths are not known when encoding starts.</li> </ul> <t>This format is designed to convey the semantics of valid HTTP messages as simply and efficiently as possible. It is not designed to capture all of the details of the encoding of messages from specific HTTP versions(<xref target="MESSAGING"/>,<xreftarget="H2"/>,target="RFC9112"/> <xreftarget="H3"/>).target="RFC9113"/> <xref target="RFC9114"/>. As such, this format is unlikely to be suitable for applications that depend on an exact recording of the encoding of messages.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>This document uses terminology from HTTP(<xref target="HTTP"/>)<xref target="RFC9110"/> and notation from QUIC (<xref section="1.3" sectionFormat="of"target="QUIC"/>).</t>target="RFC9000"/>).</t> </section> <section anchor="format"> <name>Format</name> <t><xref section="6" sectionFormat="of"target="HTTP"/>target="RFC9110"/> defines the general structure of HTTP messages and composes those messages into distinct parts. This format describes how those parts are composed into a sequence of bytes. At a high level, binary messages are comprised of:</t> <ol spacing="normal" type="1"><li>Framing indicator. This format uses a single integer to describe framing, which describes whether the message is a request or response and how subsequent sections are formatted; see <xref target="framing"/>.</li> <li>For a response, zero or more informational responses. Each informational response consists of an informational status code and header section.</li> <li>Control data. For a request, this contains the request method and target. For a response, this contains the status code.</li> <li>Header section. This contains zero or more header fields.</li> <li>Content. This is a sequence of zero or more bytes.</li> <li>Trailer section. This contains zero or more trailer fields.</li> <li>Optional padding. Any amount of zero-valued bytes.</li> </ol> <t>All lengths and numeric values are encoded using the variable-length integer encoding from <xref section="16" sectionFormat="of"target="QUIC"/>.target="RFC9000"/>. Integer values do not need to be encoded on the minimum number of bytes necessary.</t> <section anchor="known-length-messages"><name>Known Length<name>Known-Length Messages</name> <t>A request or response that has a known length at the time of construction uses the format shown in <xref target="format-known-length"/>.</t> <figure anchor="format-known-length"> <name>Known-Length Message</name><sourcecode type="quic-format"><![CDATA[ Request with<artwork name="" type="" align="left" alt=""><![CDATA[ Known-Length Request { Framing Indicator (i) = 0, Request Control Data (..), Known-Length Field Section (..), Known-Length Content (..), Known-Length Field Section (..), Padding (..), }Response withKnown-Length Response { Framing Indicator (i) = 1, Known-Length Informational Response (..) ..., Final Response Control Data (..), Known-Length Field Section (..), Known-Length Content (..), Known-Length Field Section (..), Padding (..), } Known-Length Field Section { Length (i), Field Line (..) ..., } Known-Length Content { Content Length (i), Content (..), } Known-Length Informational Response { Informational Response Control Data (..), Known-Length Field Section (..), }]]></sourcecode>]]></artwork> </figure> <t>A known-length request consists of a framing indicator (<xref target="framing"/>), request control data (<xref target="request-control"/>), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding.</t> <t>A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (<xref target="informational"/>) followed by response control data (<xref target="response-control"/>).</t> <t>For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer. This integer is the number of bytes in the field section or content, not including the length field itself.</t> <t>Fields in the header and trailer sections consist of a length-prefixed name and length-prefixed value; see <xref target="fields"/>.</t> <t>The format allows for the message to be truncated before any of the length prefixes that precede the field sections or content; see <xref target="padding"/>.</t> <t>The variable-length integer encoding means that there is a limit of2^62-12<sup>62</sup>-1 bytes for each field section and the message content.</t> </section> <section anchor="indeterminate-length-messages"><name>Indeterminate Length<name>Indeterminate-Length Messages</name> <t>A request or response that is constructed without encoding a known length for each section uses the format shown in <xref target="format-indeterminate-length"/>:</t> <figure anchor="format-indeterminate-length"> <name>Indeterminate-Length Message</name><sourcecode type="quic-format"><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Indeterminate-Length Request { Framing Indicator (i) = 2, Request Control Data (..), Indeterminate-Length Field Section (..), Indeterminate-Length Content (..), Indeterminate-Length Field Section (..), Padding (..), } Indeterminate-Length Response { Framing Indicator (i) = 3, Indeterminate-Length Informational Response (..) ..., Final Response Control Data (..), Indeterminate-Length Field Section (..), Indeterminate-Length Content (..), Indeterminate-Length Field Section (..), Padding (..), } Indeterminate-Length Content { Indeterminate-Length Content Chunk (..) ..., Content Terminator (i) = 0, } Indeterminate-Length Content Chunk { Chunk Length (i) = 1.., Chunk (..), } Indeterminate-Length Field Section { Field Line (..) ..., Content Terminator (i) = 0, } Indeterminate-Length Informational Response { Informational Response Control Data (..), Indeterminate-Length Field Section (..), }]]></sourcecode>]]></artwork> </figure> <t>An indeterminate-length request consists of a framing indicator (<xref target="framing"/>), request control data (<xref target="request-control"/>), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding.</t> <t>An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (<xref target="informational"/>) and response control data (<xref target="response-control"/>).</t> <t>The indeterminate-length encoding only uses length prefixes for content blocks. Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block. The Chunk Length is encoded as a variable-length integer.</t> <t>Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field. An Indeterminate-Length Field Section ends with a Content Terminator field. The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0.</t> <t>Indeterminate-length messages can be truncated in asimilarwayassimilar to that for known-length messages; see <xref target="padding"/>.</t> <t>Indeterminate-length messages use the same encoding forfield linesField Line as known-length messages; see <xref target="fields"/>.</t> </section> <section anchor="framing"> <name>Framing Indicator</name> <t>The start of each binary message is a framing indicator that is a single integer that describes the structure of the subsequent sections. The framing indicator can take just four values:</t> <ul spacing="normal"> <li>A value of 0 describes a request of known length.</li> <li>A value of 1 describes a response of known length.</li> <li>A value of 2 describes a request of indeterminate length.</li> <li>A value of 3 describes a response of indeterminate length.</li> </ul> <t>Other values cause the message to be invalid; see <xref target="invalid"/>.</t> </section> <section anchor="request-control"> <name>Request Control Data</name> <t>The control data for a request message contains the method and request target. That information is encoded as an ordered sequence of fields: Method, Scheme, Authority, Path. Each of these fields is prefixed with a length.</t> <t>The values of these fields follow the rules in HTTP/2 (<xref section="8.3.1" sectionFormat="of"target="H2"/>)target="RFC9113"/>) that apply to the<tt>:method</tt>, <tt>:scheme</tt>, <tt>:authority</tt>,<tt>":method"</tt>, <tt>":scheme"</tt>, <tt>":authority"</tt>, and<tt>:path</tt><tt>":path"</tt> pseudo-headerfieldsfields, respectively. However, where the<tt>:authority</tt><tt>":authority"</tt> pseudo-header field might be omitted in HTTP/2, a zero-length value is encoded instead.</t> <t>The format of request control data is shown in <xref target="format-request-control-data"/>.</t> <figure anchor="format-request-control-data"> <name>Format of Request Control Data</name><sourcecode type="quic-format"><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Request Control Data { Method Length (i), Method (..), Scheme Length (i), Scheme (..), Authority Length (i), Authority (..), Path Length (i), Path (..), }]]></sourcecode>]]></artwork> </figure> </section> <section anchor="response-control"> <name>Response Control Data</name> <t>The control data for a response message consists of the status code. The status code (<xref section="15" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) is encoded as avariable lengthvariable-length integer, not a length-prefixed decimal string.</t> <t>The format of final response control data is shown in <xref target="format-response-control-data"/>.</t> <figure anchor="format-response-control-data"> <name>Format of Final Response Control Data</name><sourcecode type="quic-format"><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Final Response Control Data { Status Code (i) = 200..599, }]]></sourcecode>]]></artwork> </figure> <section anchor="informational"> <name>Informational Status Codes</name> <t>Responses that include informational status codes (see <xref section="15.2" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) are encoded by repeating the response control data and associated header section until a finalresponse control datastatus code isencoded.encoded; that is, a Status Code field with a value from 200 to 599 (inclusive). The status code distinguishes between informational and final responses.</t> <t>The format of the informational response control data is shown in <xref target="format-informational"/>.</t> <figure anchor="format-informational"> <name>Format of Informational Response Control Data</name><sourcecode type="quic-format"><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Informational Response Control Data { Status Code (i) = 100..199, }]]></sourcecode>]]></artwork> </figure> <t>A response message can include any number of informational responses that precede a final status code. These convey an informational status code and a header block.</t> <t>If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is followed by a header section (encoded withknown-known length orindeterminate-indeterminate length according to the framing indicator) and another block of control data. This pattern repeats until the control data contains a final status code (200 to 599 inclusive).</t> </section> </section> <section anchor="fields"> <name>Header and Trailer Field Lines</name> <t>Header and trailer sections consist of zero or more field lines; see <xref section="5" sectionFormat="of"target="HTTP"/>.target="RFC9110"/>. The format of a field section depends on whether the message isknown-of known length orindeterminate-length.</t>indeterminate length.</t> <t>Eachfield lineField Line encoding includes a name and a value. Both the name and value are length-prefixed sequences of bytes. The Name fieldname lengthisat leasta minimum of one byte. The format of afield lineField Line is shown in <xref target="format-field-line"/>.</t> <figure anchor="format-field-line"> <name>Format of a Field Line</name><sourcecode type="quic-format"><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Field Line { Name Length (i) = 1.., Name (..), Value Length (i), Value (..), }]]></sourcecode>]]></artwork> </figure> <t>For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see <xref section="5.1" sectionFormat="of"target="HTTP"/>target="RFC9110"/> for a definition of what is valid and <xref target="invalid"/>forregarding the handling of invalid messages. A recipient <bcp14>MUST</bcp14> treat a message that contains field values that would cause an HTTP/2 message to be malformed according to <xref section="8.2.1" sectionFormat="of"target="H2"/>target="RFC9113"/> as invalid; see <xref target="invalid"/>.</t> <t>The same field name can be repeatedin multipleover more than one fieldlines;line; see <xref section="5.2" sectionFormat="of"target="HTTP"/>target="RFC9110"/> for the semantics of repeated field names and rules for combining values.</t> <t>Messages are invalid (<xref target="invalid"/>) if they contain fields named<tt>:method</tt>, <tt>:scheme</tt>, <tt>:authority</tt>, <tt>:path</tt>,<tt>":method"</tt>, <tt>":scheme"</tt>, <tt>":authority"</tt>, <tt>":path"</tt>, or<tt>:status</tt>.<tt>":status"</tt>. Other pseudo-fields that are defined by protocol extensions <bcp14>MAY</bcp14> be included; pseudo-fields cannot be included in trailers (see <xref section="8.1" sectionFormat="of"target="H2"/>).target="RFC9113"/>). A FieldlinesLine containing pseudo-fields <bcp14>MUST</bcp14> precede otherfield lines.Field Line values. A message that contains a pseudo-field after any other field is invalid; see <xref target="invalid"/>.</t> <t>Fields that relate to connections (<xref section="7.6.1" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) cannot be used to produce the effect on a connection in this context. These fields <bcp14>SHOULD</bcp14> be removed when constructing a binary message. However, they do not cause a message to be invalid (<xref target="invalid"/>); permitting these fields allows a binary message to capture messages that are exchanged in a protocol context.</t> <t>Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the <tt>Cookie</tt> field. Instances of fields with the ASCII-encoded value of<tt>cookie</tt><tt>"cookie"</tt> are combined using a semicolon octet (0x3b) rather than a comma; see <xref section="8.2.3" sectionFormat="of"target="H2"/>.</t>target="RFC9113"/>.</t> </section> <section anchor="content"> <name>Content</name> <t>The content of messages is a sequence of bytes of any length. Though a known-length message has a limit, this limit is large enough that it is unlikely to be a practical limitation. There is no limit to the size of content in anindeterminate lengthindeterminate-length message.</t> </section> <section anchor="padding"> <name>Padding and Truncation</name> <t>Messages can be padded with any number of zero-valued bytes. Non-zero padding bytes cause a message to be invalid (see <xref target="invalid"/>). Unlike other parts of a message, a processor <bcp14>MAY</bcp14> decide not to validate the value of padding bytes.</t> <t>Truncation can be used to reduce the size of messages that have no data in trailing field sections or content. If the trailers of a messageisare empty,itthey <bcp14>MAY</bcp14> be omitted by the encoder in place of adding a length field equal to zero. An encoder <bcp14>MAY</bcp14> omit empty content in the same way if the trailers are also empty. A message that is truncated at any other point is invalid; see <xref target="invalid"/>.</t> <t>Decoders <bcp14>MUST</bcp14> treat missing truncated fields as equivalent to having been sent with the length fieldsentset to zero.</t> <t>Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as a zero-length part, which is semantically equivalent to the part being absent.</t> </section> </section> <section anchor="invalid"> <name>Invalid Messages</name> <t>This document describes a number of ways that a message can be invalid. Invalid messages <bcp14>MUST NOT</bcp14> be processed further except to log an error and produce an error response.</t> <t>The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error might be detected after performing incremental processing.</t> </section> <section anchor="examples"> <name>Examples</name> <t>This section includes example requests and responses encoded in both known-length andindefinite-lengthindeterminate-length forms.</t> <section anchor="request-example"> <name>Request Example</name> <t>The example HTTP/1.1 message in <xref target="ex-request"/> shows the content in the<tt>message/http</tt><tt>"message/http"</tt> format.</t> <t>Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes0x0a0x0d and0x0d).0x0a). For simplicity and consistency, the content of these examples is limited to text, which also uses CRLF for line endings.</t> <figure anchor="ex-request"> <name>Sample HTTP Request</name> <sourcecode type="http-message"><![CDATA[ GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi ]]></sourcecode> </figure> <t>This can be expressed as a binary message (type<tt>message/bhttp</tt>)<tt>"message/bhttp"</tt>) using a known-length encoding as shown in hexadecimal in <xref target="ex-bink-request"/>. <xref target="ex-bink-request"/> includes text alongside to show that most of the content is not modified.</t> <figure anchor="ex-bink-request"> <name>Known-Length Binary Encoding of Request</name> <artworktype="hex-dump"><![CDATA[type=""><![CDATA[ 00034745 54056874 74707300 0a2f6865 ..GET.https../he 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a 63636570 742d6c61 6e677561 67650665 ccept-language.e 6e2c206d 690000 n, mi.. ]]></artwork> </figure> <t>This example shows that the Host header field is not replicated in the<tt>:authority</tt><tt>":authority"</tt> field, as is required for ensuring that the request is reproduced accurately; see <xref section="8.3.1" sectionFormat="of"target="H2"/>.</t>target="RFC9113"/>.</t> <t>The same message can be truncated with no effect on interpretation. In this case, the last two bytes--- corresponding to content and a trailer section--- can each be removed without altering the semantics of the message.</t> <t>The same message, encoded using anindefinite-length encodingindeterminate-length encoding, is shown in <xref target="ex-bini-request"/>. As the content of this message is empty, the difference in formats is negligible.</t> <figure anchor="ex-bini-request"><name>Indefinite-Length<name>Indeterminate-Length Binary Encoding of Request</name> <artworktype="hex-dump"><![CDATA[type=""><![CDATA[ 02034745 54056874 74707300 0a2f6865 ..GET.https../he 6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age 6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l 69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op 656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli 622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www 2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc 6570742d 6c616e67 75616765 06656e2c ept-language.en, 206d6900 00000000 00000000 00000000 mi............. ]]></artwork> </figure> <t>Thisindefinite-lengthindeterminate-length encoding contains 10 bytes of padding. As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning.</t> </section> <section anchor="response-example"> <name>Response Example</name> <t>Response messages can contain interim (1xx) statuscodescodes, as the message in <xref target="ex-response"/> shows. <xref target="ex-response"/> includes examples of informational status codes 102 and 103, as defined in <xref target="RFC2518"/> (now obsolete but defines status code 102) and <xreftarget="RFC8297"/>.</t>target="RFC8297"/>, respectively.</t> <figure anchor="ex-response"> <name>Sample HTTP Response</name> <sourcecode type="http-message"><![CDATA[ HTTP/1.1 102 Processing Running: "sleep 15" HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain Hello World! My content includes a trailing CRLF. ]]></sourcecode> </figure> <t>As this is a longer example, only theindefinite-lengthindeterminate-length encoding is shown in <xref target="ex-bini-response"/>. Note here that the specific text used in the reason phrase is not retained by this encoding.</t> <figure anchor="ex-bini-response"> <name>BinaryResponseResponse, including Informational Responses</name> <artworktype="hex-dump"><![CDATA[type=""><![CDATA[ 03406607 72756e6e 696e670a 22736c65 .@f.running."sle 65702031 35220040 67046c69 6e6b233c ep 15".@g.link#< 2f737479 6c652e63 73733e3b 2072656c /style.css>; rel 3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty 6c65046c 696e6b24 3c2f7363 72697074 le.link$</script 2e6a733e 3b207265 6c3d7072 656c6f61 .js>; rel=preloa 643b2061 733d7363 72697074 0040c804 d; as=script.@.. 64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul 20323030 39203132 3a32383a 35332047 2009 12:28:53 G 4d540673 65727665 72064170 61636865 MT.server.Apache 0d6c6173 742d6d6f 64696669 65641d57 .last-modified.W 65642c20 3232204a 756c2032 30303920 ed, 22 Jul 2009 31393a31 353a3536 20474d54 04657461 19:15:56 GMT.eta 67142233 34616133 38372d64 2d313536 g."34aa387-d-156 38656230 30220d61 63636570 742d7261 8eb00".accept-ra 6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte 6e742d6c 656e6774 68023531 04766172 nt-length.51.var 790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin 670c636f 6e74656e 742d7479 70650a74 g.content-type.t 6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello 20576f72 6c642120 4d792063 6f6e7465 World! My conte 6e742069 6e636c75 64657320 61207472 nt includes a tr 61696c69 6e672043 524c462e 0d0a0000 ailing CRLF..... ]]></artwork> </figure> <t>A response that uses the chunked encoding (see <xref section="7.1" sectionFormat="of"target="MESSAGING"/>)target="RFC9112"/>) as shownforin <xref target="ex-chunked"/> can be encoded usingindefinite-lengthindeterminate-length encoding, which minimizes buffering needed to translate into the binary format. However, chunk boundaries do not need to be retained, and any chunk extensions cannot be conveyed using the binary format; see <xref target="differences"/>.</t> <figure anchor="ex-chunked"> <name>Chunked Encoding Example</name> <sourcecode type="http-message"><![CDATA[ HTTP/1.1 200 OK Transfer-Encoding: chunked 4 This 6 conte 13;chunk-extension=foo nt contains CRLF. 0 Trailer: text ]]></sourcecode> </figure> <t><xref target="ex-bink-chunked"/> shows this message using the known-lengthcoding.encoding. Note that thetransfer-encodingTransfer-Encoding header field is removed.</t> <figure anchor="ex-bink-chunked"> <name>Known-Length Encoding of Response</name> <artworktype="hex-dump"><![CDATA[type=""><![CDATA[ 0140c800 1d546869 7320636f 6e74656e .@...This conten 7420636f 6e746169 6e732043 524c462e t contains CRLF. 0d0a0d07 74726169 6c657204 74657874 ....trailer.text ]]></artwork> </figure> </section> </section> <section anchor="differences"> <name>Notable Differences with HTTP Protocol Messages</name> <t>This format is designed to carry HTTP semantics just likeHTTP/1.1, HTTP/2,HTTP/1.1 <xref target="RFC9112"/>, HTTP/2 <xref target="RFC9113"/>, or HTTP/3(<xref target="MESSAGING"/>,<xreftarget="H2"/>, <xref target="H3"/>).target="RFC9114"/>. However, there are some notable differences between this format and the format used in an interactive protocol version.</t> <t>In particular, as a standalone representation, this format lacks the following features of the formats used in those protocols:</t> <ul spacing="normal"> <li>chunk extensions (<xref section="7.1.1" sectionFormat="of"target="MESSAGING"/>)target="RFC9112"/>) and transfer encoding (<xref section="6.1" sectionFormat="of"target="MESSAGING"/>) from HTTP/1.1</li>target="RFC9112"/>)</li> <li>generic framing and extensibility capabilities</li> <li>field blocks other than a single header and trailer field block</li> <li>carrying reason phrases in responses (<xref section="4" sectionFormat="of"target="MESSAGING"/>)</li>target="RFC9112"/>)</li> <li>header compression(<xref target="HPACK"/>,<xreftarget="QPACK"/>)</li> <li>framing of responsestarget="RFC7541"/> <xref target="RFC9204"/></li> <li>response framing that depends on the corresponding request (such as HEAD) or the value of the status code (such as 204 or 304); these responses use the same framing as all other messages</li> </ul> <t>Some of these features are also absent in HTTP/2 and HTTP/3.</t> <t>Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data rather than using pseudo-fields.</t> <t>Note that while some messages--- CONNECT or upgrade requests in particular--- can be represented using this format, doing so serves nopurposepurpose, as these requests are used to affect protocol behavior, which this format cannot do without additional mechanisms.</t> </section> <section anchor="media-type"> <name>"message/bhttp" Media Type</name> <t>The<tt>message/bhttp</tt><tt>"message/bhttp"</tt> media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.</t><dl><dl spacing="compact" newline="false"> <dt>Type name:</dt> <dd> <t>message</t> </dd> <dt>Subtype name:</dt> <dd> <t>bhttp</t> </dd> <dt>Required parameters:</dt> <dd> <t>N/A</t> </dd> <dt>Optional parameters:</dt> <dd> <t>N/A</t> </dd> <dt>Encoding considerations:</dt> <dd><t>only<t>Only "8bit" or "binary" ispermitted</t>permitted.</t> </dd> <dt>Security considerations:</dt> <dd><t>see<t>See <xreftarget="security"/></t>target="security"/>.</t> </dd> <dt>Interoperability considerations:</dt> <dd> <t>N/A</t> </dd> <dt>Published specification:</dt> <dd><t>this specification</t><t>RFC 9292</t> </dd> <dt>Applications that use this media type:</dt> <dd> <t>Applicationslookingseeking to convey HTTPrequestsemantics that are independent of a specific protocol.</t> </dd> <dt>Fragment identifier considerations:</dt> <dd> <t>N/A</t> </dd> <dt>Additional information:</dt> <dd><dl> <dt>Magic number(s):</dt> <dd>N/A</dd><dl spacing="compact" newline="false"> <dt>Deprecated alias names for this type:</dt> <dd>N/A</dd> <dt>Magic number(s):</dt> <dd>N/A</dd> <dt>File extension(s):</dt> <dd>N/A</dd> <dt>Macintosh file type code(s):</dt> <dd>N/A</dd> </dl> </dd> <dt>Personand& email address to contact for further information:</dt> <dd><t>see<t>See the Authors' Addressessection</t>section.</t> </dd> <dt>Intended usage:</dt> <dd> <t>COMMON</t> </dd> <dt>Restrictions on usage:</dt> <dd> <t>N/A</t> </dd> <dt>Author:</dt> <dd><t>see<t>See the Authors' Addressessection</t>section.</t> </dd> <dt>Change controller:</dt> <dd> <t>IESG</t> </dd> </dl> </section> <section anchor="security"> <name>Security Considerations</name> <t>Many of the considerations that apply to HTTP message handling apply to this format; see <xref section="17" sectionFormat="of"target="HTTP"/>target="RFC9110"/> and <xref section="11" sectionFormat="of"target="MESSAGING"/>target="RFC9112"/> for common issues in handling HTTP messages.</t> <t>Strict parsing of the format with no tolerance for errors can help avoid a number of attacks. However, implementations still need to be aware of the possibility of resource exhaustion attacks that might arise from receiving large messages, particularly those with large numbers of fields.</t> <t>Implementations need to ensure that they aren't subject to resource exhaustionattackattacks fromamaliciously craftedmessage.messages. Overall, the format is designed to allow for minimal state when processing messages. However, producing a combined field value (<xref section="5.2" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) for fields might require the commitment of resources. In particular, combining might be necessary for the <tt>Cookie</tt> field when translating this format for use in other contexts, such as use in an API or translation to HTTP/1.1 <xreftarget="MESSAGING"/>,target="RFC9112"/>, where the recipient of the field might not expect multiple values.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis requestedhas added the media type <tt>"message/bhttp"</tt> toaddthe "Media Types" registry at <ereftarget="https://www.iana.org/assignments/media-types"/> with the registration information intarget="https://www.iana.org/assignments/media-types" brackets="angle"/>. See <xref target="media-type"/> forthe media type "message/bhttp".</t>registration information.</t> </section> </middle> <back> <displayreferencetarget="H2"target="RFC9110" to="HTTP"/> <displayreference target="RFC9000" to="QUIC"/> <displayreference target="RFC9113" to="HTTP/2"/> <displayreferencetarget="MESSAGING"target="RFC9112" to="HTTP/1.1"/> <displayreferencetarget="H3"target="RFC7541" to="HPACK"/> <displayreference target="RFC9114" to="HTTP/3"/> <displayreference target="RFC9204" to="QPACK"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="HTTP"> <front> <title>HTTP Semantics</title> <author fullname="Roy T. Fielding"> <organization>Adobe</organization> </author> <author fullname="Mark Nottingham"> <organization>Fastly</organization> </author> <author fullname="Julian Reschke"> <organization>greenbytes GmbH</organization> </author> <date day="12" month="September" year="2021"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/> </reference> <reference anchor="QUIC"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"> <organization/> </author> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="H2"> <front> <title>HTTP/2</title> <author fullname="Martin Thomson"> <organization>Mozilla</organization> </author> <author fullname="Cory Benfield"> <organization>Apple Inc.</organization> </author> <date day="24" month="January" year="2022"/> <abstract> <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-07"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"> <organization/> </author> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><!-- draft-ietf-httpbis-semantics (RFC 9110; published) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <!-- draft-ietf-httpbis-http2bis (RFC 9113; published) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name><reference anchor="MESSAGING"> <front> <title>HTTP/1.1</title> <author fullname="Roy T. Fielding"> <organization>Adobe</organization> </author> <author fullname="Mark Nottingham"> <organization>Fastly</organization> </author> <author fullname="Julian Reschke"> <organization>greenbytes GmbH</organization> </author> <date day="12" month="September" year="2021"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging-19"/> </reference> <reference anchor="H3"> <front> <title>HTTP/3</title> <author fullname="Mike Bishop"> <organization>Akamai</organization> </author> <date day="2" month="February" year="2021"/> <abstract> <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/> </reference> <reference anchor="RFC2518"> <front> <title>HTTP Extensions for Distributed Authoring -- WEBDAV</title> <author fullname="Y. Goland" initials="Y." surname="Goland"> <organization/> </author> <author fullname="E. Whitehead" initials="E." surname="Whitehead"> <organization/> </author> <author fullname="A. Faizi" initials="A." surname="Faizi"> <organization/> </author> <author fullname="S. Carter" initials="S." surname="Carter"> <organization/> </author> <author fullname="D. Jensen" initials="D." surname="Jensen"> <organization/> </author> <date month="February" year="1999"/> <abstract> <t>This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2518"/> <seriesInfo name="DOI" value="10.17487/RFC2518"/> </reference> <reference anchor="RFC8297"> <front> <title>An HTTP Status Code for Indicating Hints</title> <author fullname="K. Oku" initials="K." surname="Oku"> <organization/> </author> <date month="December" year="2017"/> <abstract> <t>This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.</t> </abstract> </front> <seriesInfo name="RFC" value="8297"/> <seriesInfo name="DOI" value="10.17487/RFC8297"/> </reference> <reference anchor="HPACK"> <front> <title>HPACK: Header Compression for HTTP/2</title> <author fullname="R. Peon" initials="R." surname="Peon"> <organization/> </author> <author fullname="H. Ruellan" initials="H." surname="Ruellan"> <organization/> </author> <date month="May" year="2015"/> <abstract> <t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t> </abstract> </front> <seriesInfo name="RFC" value="7541"/> <seriesInfo name="DOI" value="10.17487/RFC7541"/> </reference> <reference anchor="QPACK"> <front> <title>QPACK: Field Compression for HTTP/3</title> <author fullname="Charles 'Buck' Krasic"> <organization>Netflix</organization> </author> <author fullname="Mike Bishop"> <organization>Akamai Technologies</organization> </author> <author fullname="Alan Frindell"> <organization>Facebook</organization> </author> <date day="2" month="February" year="2021"/> <abstract> <t>This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-quic-qpack-21"/> </reference><!-- draft-ietf-httpbis-messaging (RFC 9112; published) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/> <!-- draft-ietf-quic-http (RFC 9114; published) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2518.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8297.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7541.xml"/> <!-- draft-ietf-quic-qpack (RFC 9204; published) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9204.xml"/> </references> </references> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t><contact fullname="Julian Reschke"/>, <contact fullname="David Schinazi"/>, <contact fullname="LucasPardue"/>Pardue"/>, and <contact fullname="Tommy Pauly"/> provided excellent feedback on both the design and its documentation.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA81963IbOZLufzwFVj4Ra0+QJd5E2urLtEaW296xbK+t3ok5 G3vCRRYo1bjI4lQVJasdnmfZZzlPdvLLBFBAkdS4J+ZErDs6LFUVgEQiL18m EnC/31dN3hTmVB/9IV+n1b1+bzaVqc26SZu8XOtyqV9eXb3Tl6au02tTH6l0 Pq/M7am230dvVVYu1umKusuqdNn0c9Ms+zdNs5nndX/ODfor+bY/mKpF2pjr sro/1XWTqbQy6ak+e3+l7srq03VVbjen3L26NeutOVVahw+1bu43NNKf6ON8 fa1/xjt6elNifAxanx4f4++766Ssro/p3SrNi1PtqerfXf90N8ZLepdWi5u2 XZHXTZ3Iy+MzepXfmvr43XZe5IvjsAN0W5lN2Ta9zpub7TxZlCs7Ov/VN58b s66Jp/Vxkc5NUR/HDKmVNOzndb01ff7mVHe/qbfzFX1A3Vzx7F9dXL1QtBpj pdJtc1NWYFOf/tc6X9en+jLRV8SRulzzM1mcy7Rq8nX0gqZJz8tf86JI+YER Xq2an4ryjsShKjf3ydo0cffnyVlCK1BmQe/nNxUxr9zcmEqHb3mI86LcZsuC 1jocZZHe/XRj0g2t4zwnvmMctS6rFQnhLa88lpxm23+eRDJVUwfrJl/U9Mm/ //Lq/FS/f3H+bDAYoMnolMf4YU87/D2iH/iDLK83RXovcnU8UipfL8OxLy8+ fDj7+dWbnw/3J+tD5O/pcJgMQc14t/Vft/mCu9jTihZU9ft9nc7rpkoXxI+r m7zWpGDbFS2HzswyX5tap1ZEtJCMvyCPosPQC1ZQJz+J7XWVZ1lhlHqkX2Fp s+0C2n54jDpfbQpzcIx0HQ2jHn/5gt+/fn3S04ak2uD7v25N3WhuWm9IDQxE k4ZLC5KwmjulL7VZL8oMnVrToxzt9JbGXtBYc6MX5frW3JtMl9umzjPjSdhU ZVMuysJ2btbpvOC2RhEf17VdWTFtIL8ynjs9EupFseXRQUq62ZC6+6+hYGgB s5UporO63+BdAr4Z4ladX/OHDUa2vKKfRJyI1vk9d7us0hWGoIUlvm+JADtV kj1wbkR8o/lkVhA0no3pWaL1+y0mA1YRA6Q9evIsqkxxr4laDFPhWyVrmBER doienm8bocNS2NSmWIJQkkDqbtF8p2tj9JcvWb5cmoomauqvXxMrHbaVk42P duzjOQT5Y68VyLRoTLVmLdJNySP6j/lbRXNoIGcw5Dog9MsXr3I0rj7riPjG VCsiWq9KYp1ZLvNFTr0oLzhgHYkBUV1bOfLiv9NXWtQlcY0UgOZiPm/KGuvR lKo2i22VN/foiSRoxbzFwmMuce9dDbu6K4m2zC5US1bFMrKo8rnJTpX6HbHq 07q8W/cLs75ubtovRQqpvX1BmrbMP9v+SF3Ij/2FfnLapkkYVqRRxIT6O8ye +15TN5lpwCtaBLMziNMMz0B9bdam8tLuXY7Wd6TAxhJT8zzWZSO049267bRu yLXUHVGBZLFuCPNEdVkevPnGgLdpkWcxM3Vai+m5V1hUTyoJOb2hxapzmgPp xSseBVRFI6UbVi+wjNUSC9CQx6mV/TU0Nn7QZVWudL0xi5yGE4JuTcWuG7oY yGZPi7r2VKuiZ0TydnHT61qB7brIP0E9iTAyYPU2b7AAsqatoREzR2q7MTRj WgpaSPOZHADJ36KsHLGHiIeBf6TPweK1dAfGPYdu5fy72KpPtACEsrJaH13+ 8uHqqCd/6zdv+ef3F+RM3188x88fXp69fu1/UPaLDy/f/vL6eftT2/L87eXl xZvn0pie6uiROro8+zO9AVVHb99dvXr75uz1EZS+iVxPyloIRuVkIyrSAKhe CntmNQht/nD+7v/+93BCq/Av5PdHw+Gzr1/tL0+Hswn9AvGU0co18V5+JeaR QG02Jq3QC8SDRIXWoyAXAJG7gWRD6Imdv/tPcOa/TvX388VmOPnRPsCEo4eO Z9FD5tnuk53GwsQ9j/YM47kZPe9wOqb37M/R747vwcOu69/WcJpsPMqivL4X pWBdaJ0785WUTmwGfwEQBif2wTCi0MNkDPHEY6gHS+cL1gml2q+mzozSijnH AgkXi1TsesrAQpC5Y/PHBN/QX+07Ep3SOzW9YdOkdezFRJpqChvupLni71gA bb+ZdEQoCBiGvCGomN838Cf6jGRV3+TXN2Qfb03Rc/7Fm0/XEYFiwJUlWf5h ol9YDEA2GopfVklEF7MfsGt9XYgKXBOGwmwswQ5E9Eik88VNOxFASZJyxlxg oaUDFijdB8J4DTF5iixkfg3Nc2Fth8B0IYoU0AEDOziDglGCBeXOpcee/tVU JcZgB+3BdLmmlXQfgXUXKREevcZgnjAgHERhDL3WnX7I0TTbmr7J7AxMmtGM LeVE1jiBFSRsW+gsbdKWSOaAtc4AIGm+FmFzzFkR88qMeyVvdm2aBGR157jb PiCJxp8k+mVMk5U83ybikqV/mZsigxE/EfJpNVw7XsBQAqP2Io5KTUmOKvJw 3zpuYz/2A88S/XZjmbxJM/gXQk1rcrirckuyYQfuk7feMqSVcc/IhnqAAKtA ZqQi78mfiTaxu6Im29rh69u0yuEDHTaxct4iOTYpgTGZtrYETt+qhR0jKxkA rI04/7kfUVlATCKbr7Yr0DanZk6JqQXAHCktm6dH+o8MbF4LTT61oc72qg8H JTdp7cCcw2ypYOwmX/FitXCdiIF2qwCBi79h4CtP+iEuZC3729/+pjlclA/U e0vKHUVXQnDfEvyFpNVZl1fOuujH+RP9gx706KVr6tTjOamHfpwkT/Ay6uoF hEI77u/9xArpb2n/TqTK/v5V0VwsL3/bZIY7472KTITvFgPpJEnw/Ys8evU/ hgcPtAEP7AuauEwC71+Tmwzm1u3EUYXm7ue4m5jubvsDzER3B179Y8z8CtlW X071oz2yrzk7+cNR1ItVyaOv0Mnoa6egkevw8XbeClDgwp70XDOOR53DwDf2 ed8+52/TjqsRoU3jUK2nLApwEe7ej+hBE9vqQ98RxnG2eM+cW38ZOKOU7I4Y 9Z70yhHD54Vh4y5BRsCudt45It1NkS4kYfEtvhyAL3oFbLgskdeRTiIaYw7L i4DFNEPxtXtjYwbvMX8QJPFMA9xCHsixPicItuNpwtCJsQV7Eu9qrWPJhZcd f6FycSfRmFpSMhixx24oziTZYaWJJFwwT14fbfuzcsW4IxaL2gm0yLN01rdZ gYzTriwj3RfsGD1m48FsHse0+Y8o+ebQovhPclhrTnbRL0usf0o4wAafMpby qQn2g/QbiY3ZZU8d8McRZCXaU3QADbRrtTKpDY8xQGUxbZGvcmbM6P9MR/2h Ep/OmRfgy3iVmLnBPC1J1vG/ChMmvwkACL4SD0/sgsKV2ybI/cTggKhTTJ2j S8KthxDBvmTO16+nu8ggmoQzmc7nP+hQR38XHezte7+H2/tp11P+hv52POaB edpVeXCi44Nj/5MQxP94PoXg4MEPzm+260/R/N2bK9skBJd/bzjpjREJ/9Ti EeA5278f8XB/uwBpLyT6x4j9JwGfb16zHQC0N29rgdDeXkNAdCDt+48ho/0I 4VuRkbOMnpiMjDN9xpCCfVOPPUrrX9flus/RpaV6AVlgWmM81bO9KNfLDpDa HVvvGTvTAaw6yLl/AF8pHv//K74C9b8RV8HLPrwpwElSdkb7th4cpJoX5eIT Rf2X26LJsS/YBR6bsrJef+kb2Y07u7eR9cQ9+yZYHeXWPzYPDgjYHJfDVN0w 3sIoJo6RnFFxN7VPQXC4fgBvEJ84MRVYlJyz8N+g0LL94VD8G5IR9TpAfkgX flM/Zp35XqwJU4EJc51hPVuBdshsj82THOj1Nq9vwKhGcWIFH4NGHdLoEoq0 XICxVuiZXXaMQdI1nJaBPu9ql7qFj9xBTUCtSCt9l/LuTQjv/R7vPmz48Fjb 2rQK2SaOHJcIHvIOdq2icKI7XgCOAQR3gcOXR84sihrxSvMWMmQlzvkKLt21 rc4m7eZ1ZcfHpaIlmRhkvPnBbno2YQHYHYfYr5r0k9F/2dbYrN+6FBlvOp4F Kxnkv4Pk8DICq0ncZthpYw3Qw41GhwaKrNH+tuODA+5vrN5y7tsmBRepE5A4 tMnXvN3o1t/+6gVgLwr+8qjr9kQWIuO7DNPMUZzhfUeQYHbfuUTzFYtIa+q7 RgtxJrlYk0WZYJHeU8IB6LinPyxuzMr01BlXBOXNfY9gIfFGMu4iULVzXxjC W+Eo/+DjMuZkt5nE922lQVthoIP9n6fJOBnyrg2qGsQtYrfz3pcEnAo7Pvbo x5oJ5x9TR/tHcdQfTzc0hY96U5ttVvYFaihLC6QCA96a4j7RL8s7c2uqnt23 llHa/uIurJlY5dc3jSLBKCmabOJ6CUENznSIYAbrQsvaUFdxXE0zPuT9d2O7 jlj18eWDWd9YLFGiJCIV5/fsQwdIRSo639iH7hsvMZ3P2udtnEFv44/40QFM u2+KDtO+8CzbNz+gWlHJfWgbOtmBOg8ope0h0EoPhrs7OPrKP1C8yxRuap60 +5VPDuIKHeMKSQulO0mazCzylexxChCNpWiZh1DwoDCpQJhifhyWpociWQjV B2HHOc9eMgSDQZKcPHu2d4H3DLu7wg+MaRf6USfKCqioabljHNxuHtjEkIWX h3cLa/1YTH67mMkoWE4VblVx6nJj0sZhzv3rAPuU1nW5yBntxGGQ2q6bvAAg eHgl7ZgW1oX7mxF6IxvV3BnT3Q8FCfEA9Y4oNTeHIoxvEKtO/LFHnL4lON4v VkOI1XCvWMX07ojTN4wp2wS7us9pXxGWOAg9EIQJSnMZTreckcnAytWuNvHv 71mnykqKhCyEdJcPCJkvCnuw38cWZJLXkuBYO3khJvOoxGfpqyZ3+UTy6d3l D3P3LqxXLrR+7LSDwYLAakSwcWTp90EXrmrJOnyLV5XHqxLKpmQdbxwvXNzY 7t5LYn6DKoRqbZUSNVVQLdR2RjPwaGvPKunHZMRAy0nEB4v7XrY5eLeN3saB MD82UFDq5bdl66PwPohIHPB0VuhEeRNkYb2X8bSTw5bSsBrbHvsLPdShNfGw 7qLNjBcS4DrZ8psJLuJL9B9Km93wr0SwUBzSdWYOldZhicyV3w3gHgofjtP8 CpOCUWvDeftDUxci90Enft/H+wMuzgfxMD1htBslHfmFgzb/wdOLsY08OwBu WiJ2LVQaCBBM0QsfmYIZpKeYt8PYAo9tfaWUubrw2ZY3B3zk0Eb93dDGS5jF 4VJlJYgo83WBeHUHA0dclkJMLHQQGHGLG3pY2G0z+yaordUws4t8w8WkqJFT TWUwoZZAruB22ilzCad+V27picRsqQ8n2ukBoBNWsuXUkWkJQ45RG3IAkj0Q 611FqTzHV85eiI0R7q9coushDWYYoQL+7lS4+i4DAZAwMCjrXs1pScg+Cl+I xktf6lb5xdWPg3kQBGXHce+zNTYswgBZEGGpgxGWja56sBn0EZvLj7SiEkvb gMn26oTUl5bP733VvW5PuejLsz+HCb/vOt3YBFPwBW+sii3dQWlPgygycel+ ye3YSUMOohEUl2k6hy3eJVg/ltf9gplGHel0SSZU8d5n0En+oGC9CHglheO2 9HntnEQQT8ySaaicTwLebGuuZiLcgUMaEsya5ZIacm1w0KOvoeWE6+fGwxHL b1tPOjeqMqvyFv4bpdvROYK0k8miPnwwzQJma6yshqq9hieWze+cHbMQuiXI bj27McPOXOF2fPSDkfnnBRmha5dT9HLnJq3U6/yTcZaDpFnOUMTV2DeSSmmr IZy2iva5Enjl1R4hfurcGucTzsvyU24+ulTsq/ADOz+3K6DOPpy/etV3qMkn tj4ubB+2QnTOyiTVcaj0W+U0MRCyaEyjHw8+j+dPVJVah5/K6q9WadcQwf6N nbJYXOOSyD40NlLK15bKdqsLJafO5RH3Lh+EE2Pba8J0e5OptgqO9+Mtv2Vv Hj8gv0UhDjcXiMqVGZ2ieCxousAJm0LaplLBeOW2+9el7dOCyTr/1ZXX8fzE U+5LDHqRFoa4bVJBepyn5q3ERy7zHNhd6xDwxqfIoohhtyCSEIXbyrAd2roE qzn7XbYzeq32JPoX5pC1PFKajEVx2tITJUABI8kwTC7yCZkgiKYUX87Wx2Xy 0NzS5Ks3Aw7YyVq7Y4/GRLyOlfImvcVgLkZRbMA5BX+o/gOVm6JF3tgzTgqy 52a1QdIyb5R1Ii4rZ09QiS5x8T7vpHEHdkHjWhuSaMSNpcJaoJDVt0XP6FYG a8uF1u12AnYq8g6pKZ8nqUvFzXadCPYc/b4HjJZ3G5syXzddt6Fit/HcMHE1 wyct8InPe8J4+m6dAa0xvZxa8yGqEmvBq4pwD0fzlN+YjHhS28+ZJUo5VWDX sSIcgDM11nq1coGtDmaUl8EAeZIM/e+uDlAPRbF7gCPKpaIvt+EEeG/BEnmG exVPDYPha+qQV3leu7Idsr2iPF5fkSQSlu4eaGx3Elr1pWV2HiZKD7SKmbhB 2sOI7gwIWwZRQKzMtuK1FtcCwouSj0eaqiordzKNVSpdK3noj0NG+ZrOoSl2 lkBK5LxxOLsIzqARdTiduXKHtmtXAw24nN6l7SaSnJgi/Wzu7YQdZZz/xlxg ObmGiVEPnDcIkoB97+C8BhefU5BQW4bXHpLYuNLIe5cTr6Pd6zCVruekLLF7 waew6Byq+A1AUAXTFWzWWCKEjW5EdwS3NS+IHs1nl5EmrI6osvZ5kNYIqPi4 ol0ZGvM//Em1sOeaZ4fzpIJLg9IDVqbz969fID9DhuKutDoy+DxI+Wgb/ZA9 kUMKfOAtX2CNbB0jkgnEovteRKTfkLFThRNX7B1FZICHnHLxMUfe12cqgHc4 XDVrqH5tI2c+p+5OFf58caWPbwzJXdJ8btqjzL/UpuqfXRMFp3qxrYrjWTKc EuAo8nn469uNWX/48Pp4kDxLZoX+lV5Tc0Im6mVZU9O7u7vEEo6j8upsAY3p vyZwt6XhTzUOaq1y5WPtdslckP2hXWEnA0dO5a3+ms84pVy71Hxnn/YxHzzt nGB94iCY2n84Mw3SEDc0A5e/d3JFY3xqhStRex62eoE1osUpaQ3gtGnVajmI BLtf1j5tGxSzwrGviBSy5ZlbNxoh2642ajAYjCezyYk+mQxOpk9nEz2bzAaz 8WCgB+loOX06PdE6SWhpE76tIElohdV0Qf8tRwYfU5vJQE8Xg3R2Mhvr6cls NMqmQ62tHPxUJFsIQKqms+nJ1NAQ48l0TB+PqNVoOZ5RP+PheDoy47HGAa5m EoiFGg1orGdT+pjbTBda2oyHWtqMBlp3ZElNlrMBBtMn45PxhEbR4wF9+wxD zWjUwSzVOwKnZCB8PKSPR/h4PJgQD5Z6Np5NBsvZjEcSsUxuiN3JnZrRn5Eh Ps2eTofTbAZmTE/oCTFjOc0GSzAjlt2EmDGm/07o49mE2LWgb6ZmOpud4Afi 02AKxouEF1bCE2K8GRHx00xPcWUBJr7nD6tBkoR6EErT3gp5ezfHRVDl3FUQ Zx+d8bPnVaCc0WEkd64WNUu5r+Zg6xjuqdrakbSW+ia2g5k9/1xvKwn+7BiO cqmEEneYqXRBS079F/e7AU2whxwmbTrOugVIbG8JlLaRsgchNqJ4JcGyWqRy mIuMNhKRrWXuk85V4qFciskpoWRHuxVnfa67kHIQzNHG2LYSmA/Du12kKCkU wKg9c+t1jk3Z6Cb2he3B8WjnRiQlD4wRDifvuBBqtAu9+ay0P/6P/sT78fqu zXWRX/PR664BGv0TDNAg1TA+sD0axgca5A2QNT/X0J7ZBLZHiyGBorMhGU+1 GBIyLjo2P7pQsAmwPVrajGda2rB5GA1garTuujIF6wPjo2F9YHw0rA+Mj4b1 ganRuuvwFKwPjI+G9YHx0bA+MD4a1gd/tI7tz92dgvWB8dGwPjA+GtYHxkfD +sDUEA8j+7NYKFgfGB+YqyGMj4b1YdbB+sDUEIWR/Vn3YI4zGB89sH/2/KDZ /gR/OqYo75qiV62Afrs9ekCqfV5uOGjTEv5sIss0qS1+t6dIXai9W4UWhXap KEPs5oWtXJhKqkGjbzeKdH840lGvTr9tIV2gQ17j2fawVuKuCpOuHVoOahk8 ZH3f2Z+UgVw+l61XvtKPh58/P4l3s9M6tCBe8R22dvA20d3HXWxe7+x9qmig 6H6O3+O4/cnwKRLsvE+AB09Hz2Z+FybCkh4qDwcj/c7HDur9dg2unOqjujBm o4cnRyr8eKwv0qq41y+JAbV6TW7vVH9/XDf3EPy6/vE75FZ/ILNelCnF02n9 A79rv6Rob9Mkf9n7Jb8LhsO+4Ns/quckK7gKifzuaKb/bVvgxTMSgNPR01Oy AD9fXqkPpro11ak+25C5p+HIdfQvLSY71X9CdetoFLR9djo8OT2ZctuLqxQT Hk/SdPx01s/6QzKUZj4YHDkM/B4JzvrUnjayqTurSqf6ZEjxB+7Msl87pfIf ysVQQJbHm4KkB3uVZDxxUVaR/Yu+DHMdftvPp20QHyQd1O1OuuyD3fKON9lr UQQ5lUOQluNgq05cWNzY+uPf6L2cyCb6TdkYbYu6LJjw93QwlN7WrZ5XJsXt Vpubinx8C2OgUC6T5MouRDNjTzaekN0ckBkdkSE1BD7Jc5BZJec0GpFzWrAn +2mZVCLDCUSYrTC5QAKzJyNaekDpGWFOuAdqPB+Nx2yFIejJT9cJcfzTo+/V iH3C7FkLNen38diM5/AuI7Le1Kor9mpM7gEv0Qp+gZD4nOz5kGA7vZIOdVc5 4GtPQJFMZz6iVguMj0FH02dwIuRrDZP2v5wGwSeloIiHsIPK+BrUTRkVd/VM TSdCEU0HFIVDgDeLp+QRdaiNyU/kXaYTmsOEhhhmk4x6NhooeTyCqx5MKC4B N5DTTAIlVfzFYDyAY6YFGI/0OKUnT8cprQV7dvK1XVVWk4yAytQGOjOg9BkR PBkC9sPTMl65vEpqVvjE6vuAIT61YrRPNGqi+dl0ilU+odbZCY2VAFD2faT2 J2CICWZCaIDwAM0EHppnpkE46CbZiE2Hopk8o4lAoOivE2AbmgnI1rSKJ8Qn YnxoXxIScIrNhpMRCRtis+F0iB+eEjjKSEZGGXWJfjSJbGSE1JhmOx2BhQOi D1FfFNbQ2tFYYqoAOWB8KhrLAGQQMwjwjWbPaG3x28AGTIZXUsOgJZJtZuPD 4A2REhiGSAnQaDAiwoY0L1qIIUkWgTdXsnAyTG7TSs2eDZaTIXoeC96h6UzQ AY+FNTBa3yexZSRuDBYAUFqomRqZDvQDcSWFuhNww1rFPpICSQNVJixKqJJB 2JA1mMLr8eSpiDwJvdbeyCZjNrIkhiczgngIhmm1h7Skk2xGKxtxo2uKhRsD MRJkWgidTrG4CIan1AeRytyIDbYCUc60kNhOxvpkNFlMAGUH2SAV8Baa9QPg LTbv/h5I+7g9yLq/2KruFFixZfbnGfkED5lbb+Q7+7ozieyCO5WeoFhf/ADC R3YEthdCGy6vEwVFh32KzX8pvvoh/5WImm8R1KAVkqQ2U4aL4XiPli964VMk 4S1hQUkxU6Lm5XadpVW+99YJ52J6tq7pXhqFW+N+f1f5e+zaWzGioQ9dxXYY YlkYc8WX3VGo5PDBqVsLpSYMudVUWfEbjr/jd+0dlT8sy1Ktgy1xCwsGypZF CcCIcIJbaitH5/ZXD/ot1oW4tDmxdmVdIiKA0i1PIoxuHbagAa7Kszs0MmEv at00hsXsO55+yK5oQP7mBOkhsgoIHiODoeGZEn+PilkrVlj/jZgHtAu1UO8w kPUyA6qYwJxOxeVDeTVGgsVBfJwkNruQMJe7qZ8Op6PUTxxjtehMPQK/uC75 eStLkilhKPfObaUH+yih1D18p1taubtg2+QGHz8p/HY8CWfP19SXlWpvN9x3 o5pub1QLSxAqrjvTdbniLU7MRwVU+mrHcLvfHfpu71ZyJVUcV6V8cMCXEih7 1xufPOI9p3yxLdKqJylk7PNnyNia9gpMNolxiUGRLj65E93YugFAX5oUVQ0+ 6+MyKi1oxe1Vjg45rbNjOqKykeE+6ykViawL3g4qHTac7mnm7/fiJD+NzHdv Ea5254v4Aj6hw+4gLdJNyj/m2Pj5nVU0ORxo9zxtnYI977TnhoOgDU8XcoTR BLxrAe98tqTdLQpmMunOA53YYfjSLcN35aLJ71++Ozv/4w8Up85OJkORsN// Oz+LL2T9K4G8T7YrN3ku3ooKzYMqTMmohclClxB5jJsAITcvL86eP1G4Azfe iO+cOmgbwCLQx+PB5Ml3dpunJcAeaaL+pHbNrVAtNx0y5/39Y+pDuTLtZpEX QreRbfdSg+M77dWjpAO2/mDnVSzu9r4yKQINbokNy3Kj2hUx7VG9Fg3mLTrc dmHV3GdE+vr87Zs3F+dX4Mx2c13RMrc7inmorDYbOw+UNPCxnu4euW++trLU jPC5wGSzrXDrm82s1O0QfDTAFUZIeqctQJob7L6XldtxC7lj3T1BBZscUm2y iqaHiqa8Xtm7G4+i7agjMsdZnmoE9WSQV/iFEao95tLZvNL8gVyo2qnkIFNQ 8LScNrK1bm+0UN0S+R4md5szRrIVO+Xc3ItVu3x1eQGJbMhEyJ6zvZtUOfqP mAp43etUqjR5xzHY1HXGiStQQDHfH63Uqb/ZVH3YzpvoDU9T8UEo3mGgJadX ZMVrfv3m+Eyp4P6y3ZcXQVYRe25y4al8wEmKo6fzvDmCiB0JEjviE3KuGJdo cjfD7ulBwJq7O/YrXzFA45fUPHVWc7cVE8Z3i9c3KKK2KQ3+gj9gYYoeE+Tu 3hlqzQLjJycE3Dr6skDRmd/PwDmFSA5a7w1QDRNn9wlwK7jPtfhLlpV6UaXX XFuR40vEutXBKZ61Uh8kGvn991nxI43wfdb8eJle0xBSnvG4fnL6/TE9/D7L fqQ+6OfMffccmm3rbIo8rW09rdTyoQwH8z/U+AXMi3erDw1zmS4QFdSonqE2 olpkqw+2OcZU1DuSOnvhDF9yjvw0vJHbSMKNrnxK2VaMdBkCSZJTd/W/6jNp a3xlhcjVWkIgbJejCS7/fPuGc8mtWvLlMu4LWQV7T/w3DHLOtZbOigP2o9Wr iw8/s6nymnAeLTjZKa8BSl0GlwbFgqHj06DhvZ5tpXlwWJRCljgo8ke4ZkFl u+Sj/asu0nFV1iuaH9+0z57DD9e9y/kDcxKWxN32HCBJt83YlMQalH/KhicK aiR/f2OKjU5vS5TTq7bgKG0awMMgrMw7BTx1g+KpIKgMy3hUWMYjyKTcVgvI 801KmJsvOpIhbCUBF/ekuIFUcB5qonPUiikpzGwvQG9dKOdrS3crn3wnUwiK XAGS99ceyb5vm6i9B+BY/2uDg+x/gefk4sIdwpUQLmSmKPbPF3m5rYmaBf5J CeMPHKA6/Ra3wxa9cE3iwERJ3dSSK5zW9pwlAn2ufQ6u8Q5OMfhFka1pKSp0 9bkqOLQQAtH4EGF7/0Btme9Kg2yVMfmSlRhW5ZhQ842WUcDhDwO05Vn+rkpf sxyXIiuemEtodOAOt9lyTseiRFs2TQvvgKd9TcJ79u4VYIHvC0i3bKueOmFb e9a6PQPitCU4YQ0cZD7jsHZ7qMKfdEAx39mbs445IRHDQ1tXQLbNArBMorqj FiDVR0AbOVk/krZG/ed/PXb/JgeqjfJ0nfI/55HWkA/wvz5uAVX9pL3HxfYi njY6jo/NrwCEtQc9AuDVQXCJ/JML8xQhziN9tkAyozAZu82aAnvRKpP9cLQk QG4TJF/+bUtObY0YfnHziUbigOXLcwKZGU5tEzT5NXdPX28XtHTvCGdt8aW1 gV+uSNDu6fG2uMdTB+cUqhMLrqxckrKCMLiJuTvnZf8hA667a9rqSamcUP8P NdU2qjRmAAA= --></rfc>