![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 804 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- Apr 2, 2010, 10:42:06 AM (10 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (24 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r803 r804 1412 1412 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1413 1413 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2> 1414 <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 1415 <div id="rfc.figure.u.43"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1416 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1417 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1418 </pre><p id="rfc.section.6.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>. The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers 1419 that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. 1420 </p> 1421 <p id="rfc.section.6.1.p.4">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 1414 <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps.</p> 1415 <p id="rfc.section.6.1.p.2">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 1416 </p> 1417 <div id="rfc.figure.u.43"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1418 </pre><p id="rfc.section.6.1.p.4">The other formats are described here only for compatibility with obsolete implementations.</p> 1419 <div id="rfc.figure.u.44"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1420 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1421 </pre><p id="rfc.section.6.1.p.6">HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. 1422 </p> 1423 <p id="rfc.section.6.1.p.7">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 1422 1424 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 1423 1425 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 1424 1426 </p> 1425 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>1427 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 1426 1428 </pre><div id="preferred.date.format"> 1427 <p id="rfc.section.6.1.p. 6"> Preferred format:</p>1429 <p id="rfc.section.6.1.p.9"> Preferred format:</p> 1428 1430 </div> 1429 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1431 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1430 1432 1431 1433 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive … … 1463 1465 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1464 1466 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1465 </pre><p id="rfc.section.6.1.p. 8">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).1467 </pre><p id="rfc.section.6.1.p.11">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 1466 1468 </p> 1467 1469 <div id="obsolete.date.formats"> 1468 <p id="rfc.section.6.1.p. 9"> Obsolete formats:</p>1470 <p id="rfc.section.6.1.p.12"> Obsolete formats:</p> 1469 1471 </div> 1470 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>1471 </pre><div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1472 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 1473 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1472 1474 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 1473 1475 ; day-month-year (e.g., 02-Jun-82) … … 1480 1482 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1481 1483 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1482 </pre><div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>1484 </pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1483 1485 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 1484 1486 ; month day (e.g., Jun 2) 1485 </pre><div class="note" id="rfc.section.6.1.p.1 3">1487 </pre><div class="note" id="rfc.section.6.1.p.16"> 1486 1488 <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, 1487 1489 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1488 1490 </p> 1489 1491 </div> 1490 <div class="note" id="rfc.section.6.1.p.1 4">1492 <div class="note" id="rfc.section.6.1.p.17"> 1491 1493 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 1492 1494 are not required to use these formats for user presentation, request logging, etc. … … 1498 1500 is a property of the message, not of the original entity. 1499 1501 </p> 1500 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>1502 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> 1501 1503 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 6.2.2.1</a> 1502 1504 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> … … 1507 1509 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1508 1510 </div> 1509 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1511 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1510 1512 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1511 1513 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> … … 1529 1531 necessary for the recipient to verify that it has received the full message. 1530 1532 </p> 1531 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1533 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1532 1534 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1533 1535 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1572 1574 </p> 1573 1575 <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1574 <div id="rfc.figure.u.5 2"></div><pre class="text"> length := 01576 <div id="rfc.figure.u.53"></div><pre class="text"> length := 0 1575 1577 read chunk-size, chunk-ext (if any) and CRLF 1576 1578 while (chunk-size > 0) { … … 1639 1641 By convention, the products are listed in order of their significance for identifying the application. 1640 1642 </p> 1641 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1643 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1642 1644 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1643 1645 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1644 <div id="rfc.figure.u.5 4"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31646 <div id="rfc.figure.u.55"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1645 1647 Server: Apache/0.8.4 1646 1648 </pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). … … 1651 1653 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1652 1654 </p> 1653 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1655 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1654 1656 / ( "1" [ "." 0*3("0") ] ) 1655 1657 </pre><div class="note" id="rfc.section.6.4.p.3"> … … 1935 1937 </p> 1936 1938 <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p> 1937 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1939 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1938 1940 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1939 1941 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1948 1950 of the response. For example, 1949 1951 </p> 1950 <div id="rfc.figure.u.5 7"></div><pre class="text"> Connection: close1952 <div id="rfc.figure.u.58"></div><pre class="text"> Connection: close 1951 1953 </pre><p id="rfc.section.9.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1952 1954 </p> … … 1964 1966 to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET. 1965 1967 </p> 1966 <div id="rfc.figure.u.5 8"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1968 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1967 1969 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1968 1970 </pre><p id="rfc.section.9.2.p.3">An example is</p> 1969 <div id="rfc.figure.u. 59"></div><pre class="text"> Content-Length: 34951971 <div id="rfc.figure.u.60"></div><pre class="text"> Content-Length: 3495 1970 1972 </pre><p id="rfc.section.9.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 3.4</a>. 1971 1973 </p> … … 1982 1984 as the Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1983 1985 </p> 1984 <div id="rfc.figure.u.6 0"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1986 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1985 1987 <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 1986 1988 </pre><p id="rfc.section.9.3.p.3">An example is</p> 1987 <div id="rfc.figure.u.6 1"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1989 <div id="rfc.figure.u.62"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1988 1990 </pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1989 1991 </p> … … 2023 2025 resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). 2024 2026 </p> 2025 <div id="rfc.figure.u.6 2"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>2027 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 2026 2028 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 2027 2029 </pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 2028 2030 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 2029 2031 </p> 2030 <div id="rfc.figure.u.6 3"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12032 <div id="rfc.figure.u.64"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2031 2033 Host: www.example.org 2032 2034 </pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 2045 2047 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2046 2048 </p> 2047 <div id="rfc.figure.u.6 4"></div><pre class="inline"><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>2049 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 2048 2050 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 2049 2051 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) … … 2054 2056 </p> 2055 2057 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 2056 <div id="rfc.figure.u.6 5"></div><pre class="text"> TE: deflate2058 <div id="rfc.figure.u.66"></div><pre class="text"> TE: deflate 2057 2059 TE: 2058 2060 TE: trailers, deflate;q=0.5 … … 2091 2093 with chunked transfer-coding. 2092 2094 </p> 2093 <div id="rfc.figure.u.6 6"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>2095 <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 2094 2096 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2095 2097 </pre><p id="rfc.section.9.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient … … 2112 2114 are not. 2113 2115 </p> 2114 <div id="rfc.figure.u.6 7"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>2116 <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 2115 2117 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 2116 2118 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2117 2119 </pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>. An example is: 2118 2120 </p> 2119 <div id="rfc.figure.u.6 8"></div><pre class="text"> Transfer-Encoding: chunked2121 <div id="rfc.figure.u.69"></div><pre class="text"> Transfer-Encoding: chunked 2120 2122 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 2121 2123 </p> … … 2128 2130 to. 2129 2131 </p> 2130 <div id="rfc.figure.u. 69"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>2132 <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 2131 2133 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2132 2134 </pre><p id="rfc.section.9.8.p.3">For example,</p> 2133 <div id="rfc.figure.u.7 0"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112135 <div id="rfc.figure.u.71"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2134 2136 </pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 2135 2137 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2184 2186 of all senders along the request/response chain. 2185 2187 </p> 2186 <div id="rfc.figure.u.7 1"></div><pre class="inline"><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>2188 <div id="rfc.figure.u.72"></div><pre class="inline"><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 2187 2189 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2188 2190 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 2209 2211 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2210 2212 </p> 2211 <div id="rfc.figure.u.7 2"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2213 <div id="rfc.figure.u.73"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2212 2214 </pre><p id="rfc.section.9.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2213 2215 </p> … … 2215 2217 For example, 2216 2218 </p> 2217 <div id="rfc.figure.u.7 3"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2219 <div id="rfc.figure.u.74"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2218 2220 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2219 <div id="rfc.figure.u.7 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2221 <div id="rfc.figure.u.75"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2220 2222 </pre><p id="rfc.section.9.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2221 2223 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2935 2937 </p> 2936 2938 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2937 <div id="rfc.figure.u.7 5"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS2939 <div id="rfc.figure.u.76"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 2938 2940 2939 2941 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 3.4> … … 3124 3126 3125 3127 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3126 </pre> <div id="rfc.figure.u.7 6"></div>3128 </pre> <div id="rfc.figure.u.77"></div> 3127 3129 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3128 3130 ; Content-Length defined but not used
Note: See TracChangeset
for help on using the changeset viewer.
