Changeset 92


Ignore:
Timestamp:
Dec 21, 2007, 4:30:59 PM (12 years ago)
Author:
fielding@…
Message:

Regenerate HTML after the following changes applied to XML drafts:

Resolve #1: HTTP Version should be case sensitive
Resolve #2: 'unsafe' characters
Resolve #3: Chunk Size Definition
Resolve #4: Message Length
Resolve #5: Via is a MUST
Resolve #6: Fragments allowed in Location
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #9: Trailer
Resolve #11: URI includes query
Resolve #12: Invalidation after Update or Delete
Resolve #17: Revise description of the POST method
Resolve #18: Cache validators in 206 responses
Resolve #49: Connection header text
Resolve #14: Clarification regarding quoting of charset values
Resolve #47: inconsistency in date format explanation
Resolve #48: Date reference typo
Resolve #48: remove unnecessary reference to RFC1123

for consistency with draft-lafon

Resolve #16: Remove 'identity' token references
Resolve #15: No close on 1xx responses
(editorial) fix typo of varriant
Resolve #10: Safe Methods vs Redirection
Resolve #45: RFC977 reference
Resolve #42: RFC2606 compliance
Resolve #46: references to RFC1700

Location:
draft-ietf-httpbis/latest
Files:
5 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r62 r92  
    612612      </p>
    613613      <p id="rfc.section.1.1.p.4">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems,
    614          including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[RFC821]</cite></a>, NNTP <a href="#RFC977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[RFC977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
     614         including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[RFC821]</cite></a>, NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
    615615      </p>
    616616      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    675675      <dl class="empty">
    676676         <dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations
    677             is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
     677            is termed a `variant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
    678678         </dd>
    679679      </dl>
     
    809809         failing that, at least reliable indications of failure.
    810810      </p>
    811       <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[RFC1700]</cite></a>, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
     811      <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (&lt;<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>&gt;), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
    812812         or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the
    813813         mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside
     
    955955         of a message within the protocol is changed. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation.
    956956      </p>
    957       <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.</p>
     957      <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    958958      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span>       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
    959959</pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3.
     
    10131013         <li>An empty abs_path is equivalent to an abs_path of "/".</li>
    10141014      </ul>
    1015       <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
     1015      <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
    10161016      </p>
    10171017      <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
    1018       <div id="rfc.figure.u.15"></div><pre class="text">   http://abc.com:80/~smith/home.html
    1019    http://ABC.com/%7Esmith/home.html
    1020    http://ABC.com:/%7esmith/home.html
     1018      <div id="rfc.figure.u.15"></div><pre class="text">   http://example.com:80/~smith/home.html
     1019   http://EXAMPLE.com/%7Esmith/home.html
     1020   http://EXAMPLE.com:/%7esmith/home.html
    10211021</pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
    10221022      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
    10231023      <p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
    10241024      <div id="rfc.figure.u.16"></div><pre class="text">   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
    1025    Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
     1025   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    10261026   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    1027 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[RFC1036]</cite></a> date format and lacks a four-digit year. 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&nbsp;B</a> for further information.
     1027</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
     1028         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&nbsp;B</a> for further information.
    10281029      </p>
    10291030      <dl class="empty">
     
    10801081      </p>
    10811082      <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
    1082          contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>), "identity" (section 3.6.2), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1083         contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    10831084      </p>
    10841085      <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     
    11061107    chunk-data     = chunk-size(OCTET)
    11071108    trailer        = *(entity-header CRLF)
    1108 </pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk
    1109          whose size is zero, followed by the trailer, which is terminated by an empty line.
     1109</pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
     1110         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    11101111      </p>
    11111112      <p id="rfc.section.3.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     
    12211222         </li>
    12221223         <li>
    1223             <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding
    1224                (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>), unless the message is terminated by closing the connection.
     1224            <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a>) is present, then the transfer-length is defined by use of the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>), unless the message is terminated by closing the connection.
    12251225            </p>
    12261226         </li>
     
    12321232         </li>
    12331233         <li>
    1234             <p>If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting
    1235                media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse
    1236                it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient
    1237                can parse multipart/byteranges responses.
     1234            <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting
     1235               media type defines the transfer-length. This media type <em class="bcp14">MUST NOT</em> be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple
     1236               byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
    12381237            </p>
    12391238            <dl class="empty">
     
    12541253      <p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
    12551254      </p>
    1256       <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity
    1257          transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
     1255      <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
    12581256      </p>
    12591257      <p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.
     
    12971295      <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>) and identifies the resource upon which to apply the request.
    12981296      </p>
    1299       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span>    Request-URI    = "*" | absoluteURI | abs_path | authority
     1297      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span>    Request-URI    = "*"
     1298                   | absoluteURI
     1299                   | ( abs_path [ "?" query ] )
     1300                   | authority
    13001301</pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
    13011302         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
     
    13081309         Request-Line would be:
    13091310      </p>
    1310       <div id="rfc.figure.u.32"></div><pre class="text">    GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
     1311      <div id="rfc.figure.u.32"></div><pre class="text">    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    13111312</pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    13121313      </p>
     
    13151316      <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
    13161317         path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section&nbsp;3.2.1</a>, abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
    1317          server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
     1318         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    13181319      </p>
    13191320      <div id="rfc.figure.u.33"></div><pre class="text">    GET /pub/WWW/TheProject.html HTTP/1.1
    1320     Host: www.w3.org
     1321    Host: www.example.org
    13211322</pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
    13221323         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
     
    15871588</pre><p id="rfc.section.8.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&nbsp;7.1</a>) after the current request/response is complete.
    15881589      </p>
    1589       <p id="rfc.section.8.1.p.9">HTTP/1.1 applications that do not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every message.
    1590       </p>
    1591       <p id="rfc.section.8.1.p.10">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token
     1590      <p id="rfc.section.8.1.p.9">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
     1591      </p>
     1592      <p id="rfc.section.8.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (informational) status code.
     1593      </p>
     1594      <p id="rfc.section.8.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token
    15921595         in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects
    15931596         against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;D.2</a>.
     
    16141617      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    16151618      <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics
    1616          as orig-date in RFC 822. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>-date format.
     1619         as orig-date in RFC 822. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16171620      </p>
    16181621      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
     
    16561659      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.74"></span>    Host = "Host" ":" host [ ":" port ] ; <a href="#http.url" title="http URL">Section&nbsp;3.2.2</a>
    16571660</pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
    1658          URL). For example, a request on the origin server for &lt;http://www.w3.org/pub/WWW/&gt; would properly include:
     1661         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    16591662      </p>
    16601663      <div id="rfc.figure.u.44"></div><pre class="text">    GET /pub/WWW/ HTTP/1.1
    1661     Host: www.w3.org
     1664    Host: www.example.org
    16621665</pre><p id="rfc.section.8.4.p.5">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
    16631666         for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being
     
    18001803      </p>
    18011804      <p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    1802          HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin
    1803          server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:
    1804       </p>
    1805       <div id="rfc.figure.u.53"></div><pre class="text">    Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
     1805         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
     1806         server at www.example.com. The request received by www.example.com would then have the following Via header field:
     1807      </p>
     1808      <div id="rfc.figure.u.53"></div><pre class="text">    Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    18061809</pre><p id="rfc.section.8.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.
    18071810      </p>
     
    19351938      <h1 id="rfc.references"><a href="#rfc.section.12" id="rfc.section.12">12.</a> References
    19361939      </h1>
    1937       <table summary="References">                                                                   
     1940      <table summary="References">                                                               
    19381941         <tr>
    19391942            <td class="reference"><b id="ISO-8859">[ISO-8859]</b></td>
     
    19701973         </tr>
    19711974         <tr>
    1972             <td class="reference"><b id="RFC1036">[RFC1036]</b></td>
    1973             <td class="top">Horton, M. and R. Adams, “<a href="http://tools.ietf.org/html/rfc1036">Standard for interchange of USENET messages</a>”, RFC&nbsp;1036, December&nbsp;1987.
    1974             </td>
    1975          </tr>
    1976          <tr>
    19771975            <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
    19781976            <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
     
    19871985            <td class="reference"><b id="RFC1436">[RFC1436]</b></td>
    19881986            <td class="top"><a title="University of Minnesota, Computer and Information Services">Anklesaria, F.</a>, <a title="University of Minnesota, Computer and Information Services">McCahill, M.</a>, <a title="University of Minnesota, Computer and Information Services">Lindner, P.</a>, <a title="University of Minnesota, Computer and Information Services">Johnson, D.</a>, <a title="University of Minnesota, Computer and Information Services">Torrey, D.</a>, and <a title="University of Minnesota, Computer and Information Services">B. Alberti</a>, “<a href="http://tools.ietf.org/html/rfc1436">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</a>”, RFC&nbsp;1436, March&nbsp;1993.
    1989             </td>
    1990          </tr>
    1991          <tr>
    1992             <td class="reference"><b id="RFC1590">[RFC1590]</b></td>
    1993             <td class="top"><a title="USC/Information Sciences Institute">Postel, J.</a>, “<a href="http://tools.ietf.org/html/rfc1590">Media Type Registration Procedure</a>”, RFC&nbsp;1590, November&nbsp;1996.
    19941987            </td>
    19951988         </tr>
     
    20011994         </tr>
    20021995         <tr>
    2003             <td class="reference"><b id="RFC1700">[RFC1700]</b></td>
    2004             <td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <a title="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD&nbsp;2, RFC&nbsp;1700, October&nbsp;1994.
    2005             </td>
    2006          </tr>
    2007          <tr>
    20081996            <td class="reference"><b id="RFC1737">[RFC1737]</b></td>
    20091997            <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC&nbsp;1737, December&nbsp;1994.
     
    20712059         </tr>
    20722060         <tr>
     2061            <td class="reference"><b id="RFC3977">[RFC3977]</b></td>
     2062            <td class="top"><a title="THUS plc">Feather, C.</a>, “Network News Transfer Protocol (NNTP)”, October&nbsp;2006.
     2063            </td>
     2064         </tr>
     2065         <tr>
     2066            <td class="reference"><b id="RFC4288">[RFC4288]</b></td>
     2067            <td class="top"><a title="Sun Microsystems">Freed, N.</a> and <a>J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
     2068            </td>
     2069         </tr>
     2070         <tr>
    20732071            <td class="reference"><b id="RFC821">[RFC821]</b></td>
    20742072            <td class="top">Postel, J.B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD&nbsp;10, RFC&nbsp;821, August&nbsp;1982.
     
    20832081            <td class="reference"><b id="RFC959">[RFC959]</b></td>
    20842082            <td class="top">Postel, J. and J. Reynolds, “<a href="http://tools.ietf.org/html/rfc959">File Transfer Protocol</a>”, STD&nbsp;9, RFC&nbsp;959, October&nbsp;1985.
    2085             </td>
    2086          </tr>
    2087          <tr>
    2088             <td class="reference"><b id="RFC977">[RFC977]</b></td>
    2089             <td class="top">Kantor, B. and P. Lapsley, “<a href="http://tools.ietf.org/html/rfc977">Network News Transfer Protocol</a>”, RFC&nbsp;977, February&nbsp;1986.
    20902083            </td>
    20912084         </tr>
     
    21282121         it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can
    21292122         be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered
    2130          with IANA <a href="#RFC1590" id="rfc.xref.RFC1590.1"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a>.
     2123         with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
    21312124      </p>
    21322125      <p id="rfc.section.A.p.2"> </p>
     
    25142507                  <li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">1.3</a></li>
    25152508                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">1.3</a></li>
    2516                   <li class="indline1"><em>RFC1036</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1036.1">3.3.1</a>, <a class="iref" href="#RFC1036"><b>12</b></a></li>
    2517                   <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC1123.2">8.3</a>, <a class="iref" href="#RFC1123"><b>12</b></a></li>
     2509                  <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#RFC1123"><b>12</b></a></li>
    25182510                  <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12</b></a></li>
    25192511                  <li class="indline1"><em>RFC1436</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1436.1">1.1</a>, <a class="iref" href="#RFC1436"><b>12</b></a></li>
    2520                   <li class="indline1"><em>RFC1590</em>&nbsp;&nbsp;<a class="iref" href="#RFC1590"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC1590.1">A</a></li>
    25212512                  <li class="indline1"><em>RFC1630</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1630.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1630.2">3.2</a>, <a class="iref" href="#RFC1630"><b>12</b></a></li>
    2522                   <li class="indline1"><em>RFC1700</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1700.1">1.4</a>, <a class="iref" href="#RFC1700"><b>12</b></a></li>
    25232513                  <li class="indline1"><em>RFC1737</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1737.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1737.2">3.2</a>, <a class="iref" href="#RFC1737"><b>12</b></a></li>
    25242514                  <li class="indline1"><em>RFC1738</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1738.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1738.2">3.2</a>, <a class="iref" href="#rfc.xref.RFC1738.3">3.2.1</a>, <a class="iref" href="#RFC1738"><b>12</b></a></li>
     
    25372527                  <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.3">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12</b></a></li>
    25382528                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>12</b></a></li>
     2529                  <li class="indline1"><em>RFC3977</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3977.1">1.1</a>, <a class="iref" href="#RFC3977"><b>12</b></a></li>
     2530                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li>
    25392531                  <li class="indline1"><em>RFC821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li>
    25402532                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind">
     
    25432535                  </li>
    25442536                  <li class="indline1"><em>RFC959</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC959.1">1.1</a>, <a class="iref" href="#RFC959"><b>12</b></a></li>
    2545                   <li class="indline1"><em>RFC977</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC977.1">1.1</a>, <a class="iref" href="#RFC977"><b>12</b></a></li>
    25462537               </ul>
    25472538            </li>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r62 r92  
    825825      <div id="rfc.iref.m.4"></div>
    826826      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    827       <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of
    828          the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following
    829          functions:
     827      <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed
     828         by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the
     829         following functions:
    830830      </p>
    831831      <ul>
     
    835835         <li>Extending a database through an append operation.</li>
    836836      </ul>
    837       <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
    838          The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news
    839          article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
    840       </p>
     837      <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p>
    841838      <p id="rfc.section.8.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
    842839         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
     
    10511048      <p id="rfc.section.9.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    10521049      </p>
    1053       <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1050      <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    10541051         the request was issued.
    10551052      </p>
     
    10681065      <p id="rfc.section.9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    10691066      </p>
    1070       <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1067      <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    10711068         the request was issued.
    10721069      </p>
     
    11221119         the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
    11231120      </p>
    1124       <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1121      <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    11251122         the request was issued.
    11261123      </p>
     
    13711368      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    From   = "From" ":" mailbox
    13721369</pre><p id="rfc.section.10.3.p.3">An example is:</p>
    1373       <div id="rfc.figure.u.11"></div><pre class="text">    From: webmaster@w3.org
     1370      <div id="rfc.figure.u.11"></div><pre class="text">    From: webmaster@example.org
    13741371</pre><p id="rfc.section.10.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    13751372         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving
     
    13911388         URI.
    13921389      </p>
    1393       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span>    Location       = "Location" ":" absoluteURI
     1390      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span>    Location       = "Location" ":" absoluteURI [ "#" fragment ]
    13941391</pre><p id="rfc.section.10.4.p.3">An example is:</p>
    1395       <div id="rfc.figure.u.13"></div><pre class="text">    Location: http://www.w3.org/pub/WWW/People.html
     1392      <div id="rfc.figure.u.13"></div><pre class="text">    Location: http://www.example.org/pub/WWW/People.html
    13961393</pre><p id="rfc.section.10.4.p.5"> </p>
    13971394      <dl class="empty">
     
    14231420      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span>    Referer        = "Referer" ":" ( absoluteURI | relativeURI )
    14241421</pre><p id="rfc.section.10.6.p.3">Example:</p>
    1425       <div id="rfc.figure.u.16"></div><pre class="text">    Referer: http://www.w3.org/hypertext/DataSources/Overview.html
     1422      <div id="rfc.figure.u.16"></div><pre class="text">    Referer: http://www.example.org/hypertext/Overview.html
    14261423</pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section&nbsp;12.2</a> for security considerations.
    14271424      </p>
     
    14491446</pre><p id="rfc.section.10.8.p.3">Example:</p>
    14501447      <div id="rfc.figure.u.20"></div><pre class="text">    Server: CERN/3.0 libwww/2.17
    1451 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">SHOULD</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1448</pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    14521449      </p>
    14531450      <dl class="empty">
  • draft-ietf-httpbis/latest/p3-payload.html

    r62 r92  
    558558      </dl>
    559559      <p id="rfc.section.2.1.p.4">HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character
    560          Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[RFC1700]</cite></a>.
     560         Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;).
    561561      </p>
    562562      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>    charset = token
    563563</pre><p id="rfc.section.2.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA
    564          Character Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.2"><cite title="Assigned Numbers">[RFC1700]</cite></a>  <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry.
    565       </p>
    566       <p id="rfc.section.2.1.p.7">Implementors should be aware of IETF character set requirements <a href="#RFC2279" id="rfc.xref.RFC2279.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC2279]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
     564         Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry.
     565      </p>
     566      <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token)
     567         and as the value of a parameter in a Content-type header (within a request or response), in which case the parameter value
     568         of the charset parameter may be quoted.
     569      </p>
     570      <p id="rfc.section.2.1.p.8">Implementors should be aware of IETF character set requirements <a href="#RFC2279" id="rfc.xref.RFC2279.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC2279]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
    567571      </p>
    568572      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
     
    621625      </p>
    622626      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    623       <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC1590" id="rfc.xref.RFC1590.1"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
     627      <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
    624628      </p>
    625629      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>    media-type     = type "/" subtype *( ";" parameter )
     
    638642         implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition.
    639643      </p>
    640       <p id="rfc.section.2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA <a href="#RFC1700" id="rfc.xref.RFC1700.3"><cite title="Assigned Numbers">[RFC1700]</cite></a>). The media type registration process is outlined in RFC 1590 <a href="#RFC1590" id="rfc.xref.RFC1590.2"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a>. Use of non-registered media types is discouraged.
     644      <p id="rfc.section.2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
     645         outlined in RFC 4288 <a href="#RFC4288" id="rfc.xref.RFC4288.2"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged.
    641646      </p>
    642647      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>
     
    11631168      <h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References
    11641169      </h1>
    1165       <table summary="References">                                                 
     1170      <table summary="References">                                               
    11661171         <tr>
    11671172            <td class="reference"><b id="Part1">[Part1]</b></td>
     
    11901195         </tr>
    11911196         <tr>
    1192             <td class="reference"><b id="RFC1590">[RFC1590]</b></td>
    1193             <td class="top"><a title="USC/Information Sciences Institute">Postel, J.</a>, “<a href="http://tools.ietf.org/html/rfc1590">Media Type Registration Procedure</a>”, RFC&nbsp;1590, November&nbsp;1996.
    1194             </td>
    1195          </tr>
    1196          <tr>
    1197             <td class="reference"><b id="RFC1700">[RFC1700]</b></td>
    1198             <td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <a title="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD&nbsp;2, RFC&nbsp;1700, October&nbsp;1994.
    1199             </td>
    1200          </tr>
    1201          <tr>
    12021197            <td class="reference"><b id="RFC1766">[RFC1766]</b></td>
    12031198            <td class="top"><a title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC&nbsp;1766, March&nbsp;1995.
     
    12821277            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    12831278            <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     1279            </td>
     1280         </tr>
     1281         <tr>
     1282            <td class="reference"><b id="RFC4288">[RFC4288]</b></td>
     1283            <td class="top"><a title="Sun Microsystems">Freed, N.</a> and <a>J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
    12841284            </td>
    12851285         </tr>
     
    13391339      </p>
    13401340      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
    1341       <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols
    1342          to HTTP <em class="bcp14">MUST</em> remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP
    1343          client.
     1341      <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
    13441342      </p>
    13451343      <p id="rfc.section.A.4.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
     
    15641562            </li>
    15651563            <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
    1566                   <li class="indline1"><em>RFC1590</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1590.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC1590.2">2.3</a>, <a class="iref" href="#RFC1590"><b>9</b></a></li>
    1567                   <li class="indline1"><em>RFC1700</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1700.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC1700.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC1700.3">2.3</a>, <a class="iref" href="#RFC1700"><b>9</b></a></li>
    15681564                  <li class="indline1"><em>RFC1766</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1766.1">2.5</a>, <a class="iref" href="#RFC1766"><b>9</b></a></li>
    15691565                  <li class="indline1"><em>RFC1806</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1806.1">7.2</a>, <a class="iref" href="#RFC1806"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1806.2">B.1</a></li>
     
    15891585                  <li class="indline1"><em>RFC2279</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2279.1">2.1</a>, <a class="iref" href="#RFC2279"><b>9</b></a></li>
    15901586                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>9</b></a></li>
     1587                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC4288.2">2.3</a>, <a class="iref" href="#RFC4288"><b>9</b></a></li>
    15911588                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#RFC822"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC822.1">A</a></li>
    15921589               </ul>
  • draft-ietf-httpbis/latest/p5-range.html

    r62 r92  
    528528         </li>
    529529      </ul>
    530       <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request that used a strong cache validator (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the
    531          response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
     530      <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise, the response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
    532531      </p>
    533532      <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Byte Ranges">4</a>.
     
    554553      <ul>
    555554         <li>Both the incoming response and the cache entry have a cache validator.</li>
    556          <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     555         <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    557556         </li>
    558557      </ul>
     
    948947            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    949948                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">7</a>, <a class="iref" href="#Part1"><b>9</b></a></li>
    950                   <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.1</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind">
    951                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.1</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a></li>
     949                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind">
     950                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">4</a></li>
    952951                     </ul>
    953952                  </li>
  • draft-ietf-httpbis/latest/p6-cache.html

    r62 r92  
    993993         <li>Proxy-Authorization</li>
    994994         <li>TE</li>
    995          <li>Trailers</li>
     995         <li>Trailer</li>
    996996         <li>Transfer-Encoding</li>
    997997         <li>Upgrade</li>
    998998      </ul>
    999999      <p id="rfc.section.2.5.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p>
    1000       <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header, (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to be introduced into HTTP/1.1 (or later).
     1000      <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    10011001      </p>
    10021002      <h3 id="rfc.section.2.5.2"><a href="#rfc.section.2.5.2">2.5.2</a>&nbsp;<a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h3>
     
    11431143         <li>POST</li>
    11441144      </ul>
    1145       <p id="rfc.section.2.10.p.5">In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST</em> only be performed if the host part is the same as in the Request-URI.
     1145      <p id="rfc.section.2.10.p.5">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service
     1146         attacks.
    11461147      </p>
    11471148      <p id="rfc.section.2.10.p.6">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate any entities referred to by the Request-URI.
Note: See TracChangeset for help on using the changeset viewer.