Changeset 1335 for draft-ietf-httpbis/latest
- Timestamp:
- 19/07/11 07:13:24 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1333 r1335 359 359 } 360 360 @bottom-center { 361 content: "Expires January 19, 2012";361 content: "Expires January 20, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-07-1 8">411 <meta name="dct.issued" scheme="ISO8601" content="2011-07-19"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: January 19, 2012</td>442 <td class="left">Expires: January 20, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">July 1 8, 2011</td>495 <td class="right">July 19, 2011</td> 496 496 </tr> 497 497 </tbody> … … 522 522 in progress”. 523 523 </p> 524 <p>This Internet-Draft will expire on January 19, 2012.</p>524 <p>This Internet-Draft will expire on January 20, 2012.</p> 525 525 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 526 526 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1801 1801 <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1802 1802 <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1803 not acceptable according to the accept header fields sent in the request.1803 not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1804 1804 </p> 1805 1805 <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user … … 2050 2050 </div> 2051 2051 <div class="note" id="rfc.section.9.4.p.9"> 2052 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.2052 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2053 2053 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2054 2054 </p> … … 3062 3062 </ul> 3063 3063 <h2 id="rfc.section.C.17"><a href="#rfc.section.C.17">C.17</a> <a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p2-semantics-15</a></h2> 3064 <p id="rfc.section.C.17.p.1">None yet.</p> 3064 <p id="rfc.section.C.17.p.1">Closed issues: </p> 3065 <ul> 3066 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>>: "Strength of requirements on Accept re: 406" 3067 </li> 3068 </ul> 3065 3069 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 3066 3070 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> … … 3236 3240 </ul> 3237 3241 </li> 3238 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3</a>, <a href="#rfc.xref.Part3.2">3</a>, <a href="#rfc.xref.Part3.3">3</a>, <a href="#rfc.xref.Part3.4">3</a>, <a href="#rfc.xref.Part3.5">6</a>, <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.7">8.3.1</a>, <a href="#rfc.xref.Part3.8"> 9.4</a>, <a href="#Part3"><b>13.1</b></a><ul>3242 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3</a>, <a href="#rfc.xref.Part3.2">3</a>, <a href="#rfc.xref.Part3.3">3</a>, <a href="#rfc.xref.Part3.4">3</a>, <a href="#rfc.xref.Part3.5">6</a>, <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.7">8.3.1</a>, <a href="#rfc.xref.Part3.8">8.4.7</a>, <a href="#rfc.xref.Part3.9">9.4</a>, <a href="#Part3"><b>13.1</b></a><ul> 3239 3243 <li><em>Section 5</em> <a href="#rfc.xref.Part3.7">8.3.1</a></li> 3240 3244 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">3</a></li> 3245 <li><em>Section 6</em> <a href="#rfc.xref.Part3.8">8.4.7</a></li> 3241 3246 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">3</a></li> 3242 3247 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">3</a></li> 3243 3248 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">3</a></li> 3244 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3. 8">9.4</a></li>3249 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.9">9.4</a></li> 3245 3250 </ul> 3246 3251 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1326 r1335 74 74 <!ENTITY status-412 "<xref target='Part4' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 75 75 <!ENTITY status-416 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 76 <!ENTITY p3-header-fields "<xref target='Part3' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 76 77 <!ENTITY p4-status-codes "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 77 78 <!ENTITY p5-status-codes "<xref target='Part5' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1817 1818 The resource identified by the request is only capable of generating 1818 1819 response representations which have content characteristics not acceptable 1819 according to the accept header fields sent in the request. 1820 according to the Accept and Accept-* header fields sent in the request 1821 (see &p3-header-fields;). 1820 1822 </t> 1821 1823 <t> … … 4158 4160 <section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15"> 4159 4161 <t> 4160 None yet. 4162 Closed issues: 4163 <list style="symbols"> 4164 <t> 4165 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>: 4166 "Strength of requirements on Accept re: 406" 4167 </t> 4168 </list> 4161 4169 </t> 4162 4170 </section> -
draft-ietf-httpbis/latest/p3-payload.html
r1333 r1335 359 359 } 360 360 @bottom-center { 361 content: "Expires January 19, 2012";361 content: "Expires January 20, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-07-1 8">410 <meta name="dct.issued" scheme="ISO8601" content="2011-07-19"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 19, 2012</td>436 <td class="left">Expires: January 20, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">July 1 8, 2011</td>493 <td class="right">July 19, 2011</td> 494 494 </tr> 495 495 </tbody> … … 519 519 in progress”. 520 520 </p> 521 <p>This Internet-Draft will expire on January 19, 2012.</p>521 <p>This Internet-Draft will expire on January 20, 2012.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 989 989 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 990 990 </ol> 991 <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 991 <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honour 992 them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response 993 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 994 </p> 995 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 996 </p> 997 <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 992 998 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 993 999 within extension header fields not defined by this specification. 994 1000 </p> 995 <div class="note" id="rfc.section.5.1.p. 5">1001 <div class="note" id="rfc.section.5.1.p.7"> 996 1002 <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized. 997 1003 </p> 998 1004 </div> 999 <p id="rfc.section.5.1.p. 6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.1005 <p id="rfc.section.5.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 1000 1006 </p> 1001 1007 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> … … 1040 1046 <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 1041 1047 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1042 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.1048 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1043 1049 </p> 1044 1050 <div class="note" id="rfc.section.6.1.p.5"> … … 1055 1061 </p> 1056 1062 <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field 1057 is present , and if the server cannot send a response which is acceptable according to the combined Accept field value, then1058 the server <em class="bcp14">SHOULD</em> senda 406 (Not Acceptable) response.1063 is present in a request, but the server cannot send a response which is acceptable, then the server can either send a response 1064 in another format, or a 406 (Not Acceptable) response. 1059 1065 </p> 1060 1066 <p id="rfc.section.6.1.p.10">A more elaborate example is</p> … … 1138 1144 </p> 1139 1145 <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character encoding is acceptable. If an Accept-Charset 1140 header field is present , and if the server cannot send a response which is acceptable according to the Accept-Charset header1141 field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.1146 header field is present in a request, but the server cannot send a response which is acceptable, then the server can either 1147 use another character encoding, or send a 406 (Not Acceptable) response. 1142 1148 </p> 1143 1149 <div id="rfc.iref.a.3"></div> … … 1159 1165 <ol> 1160 1166 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it 1161 is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)1167 is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 1162 1168 </li> 1163 1169 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header … … 1170 1176 </li> 1171 1177 </ol> 1172 <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according 1173 to the Accept-Encoding header field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code. 1178 <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, but the server cannot send a response which is acceptable, then the server <em class="bcp14">SHOULD</em> send a response without any encoding (i.e., the "identity" encoding). 1174 1179 </p> 1175 1180 <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, … … 1279 1284 </p> 1280 1285 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1281 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1286 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1282 1287 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1283 1288 </p> … … 1427 1432 <td class="left">compress</td> 1428 1433 <td class="left">UNIX "compress" program method</td> 1429 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1434 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1430 1435 </td> 1431 1436 </tr> … … 1434 1439 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 1435 1440 </td> 1436 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1441 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1437 1442 </td> 1438 1443 </tr> … … 1440 1445 <td class="left">gzip</td> 1441 1446 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 1442 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1447 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1443 1448 </td> 1444 1449 </tr> … … 1696 1701 </p> 1697 1702 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2> 1698 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.1703 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 1699 1704 </p> 1700 1705 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> … … 1713 1718 </p> 1714 1719 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1715 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1720 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1716 1721 </p> 1717 1722 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 2019 2024 <p id="rfc.section.E.16.p.1">None.</p> 2020 2025 <h2 id="rfc.section.E.17"><a href="#rfc.section.E.17">E.17</a> <a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p3-payload-15</a></h2> 2021 <p id="rfc.section.E.17.p.1">None yet.</p> 2026 <p id="rfc.section.E.17.p.1">Closed issues: </p> 2027 <ul> 2028 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>>: "Strength of requirements on Accept re: 406" 2029 </li> 2030 </ul> 2022 2031 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 2023 2032 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> … … 2113 2122 </li> 2114 2123 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2115 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16"> 6.1</a>, <a href="#rfc.xref.Part1.17">6.3</a>, <a href="#rfc.xref.Part1.18">6.7</a>, <a href="#rfc.xref.Part1.19">7.2</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.22">A.3</a>, <a href="#rfc.xref.Part1.23">A.6</a><ul>2124 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.23">A.3</a>, <a href="#rfc.xref.Part1.24">A.6</a><ul> 2116 2125 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2117 2126 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a></li> 2118 2127 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a></li> 2119 2128 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">3.2</a></li> 2120 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 8">6.7</a></li>2121 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.2 2">A.3</a></li>2129 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.19">6.7</a></li> 2130 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.23">A.3</a></li> 2122 2131 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.12">2.2.1</a></li> 2123 <li><em>Section 6.2.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1. 19">7.2</a></li>2132 <li><em>Section 6.2.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li> 2124 2133 <li><em>Section 6.2.2</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2125 <li><em>Section 6.2.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.2 0">7.2</a></li>2126 <li><em>Section 6.2.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.2 1">7.2</a></li>2127 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16"> 6.1</a>, <a href="#rfc.xref.Part1.17">6.3</a></li>2134 <li><em>Section 6.2.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2135 <li><em>Section 6.2.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2136 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li> 2128 2137 <li><em>Section 9.2</em> <a href="#rfc.xref.Part1.14">3.1</a></li> 2129 <li><em>Section 9.7</em> <a href="#rfc.xref.Part1.2 3">A.6</a></li>2138 <li><em>Section 9.7</em> <a href="#rfc.xref.Part1.24">A.6</a></li> 2130 2139 </ul> 2131 2140 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r1328 r1335 845 845 </t> 846 846 <t> 847 Server-driven negotiation allows the user agent to specify its preferences, 848 but it cannot expect responses to always honour them. For example, the origin 849 server might not implement server-driven negotiation, or it might decide that 850 sending a response that doesn't conform to them is better than sending a 406 851 (Not Acceptable) response. 852 </t> 853 <t> 854 Many of the mechanisms for expressing preferences use quality values to 855 declare relative preference. See &qvalue; for more information. 856 </t> 857 <t> 847 858 HTTP/1.1 includes the following header fields for enabling 848 859 server-driven negotiation through description of user agent … … 973 984 <t> 974 985 If no Accept header field is present, then it is assumed that the 975 client accepts all media types. If an Accept header field is present ,976 and if the server cannot send a response which is acceptable977 according to the combined Accept field value, then the server &SHOULD;978 send a 406 (Not Acceptable) response.986 client accepts all media types. If an Accept header field is present in a 987 request, but the server cannot send a response which is acceptable, then 988 the server can either send a response in another format, or a 406 (Not 989 Acceptable) response. 979 990 </t> 980 991 <t> … … 1070 1081 <t> 1071 1082 If no Accept-Charset header field is present, the default is that any 1072 character encoding is acceptable. If an Accept-Charset header field is present, 1073 and if the server cannot send a response which is acceptable 1074 according to the Accept-Charset header field, then the server &SHOULD; send 1075 an error response with the 406 (Not Acceptable) status code, though 1076 the sending of an unacceptable response is also allowed. 1083 character encoding is acceptable. If an Accept-Charset header field is 1084 present in a request, but the server cannot send a response which is 1085 acceptable, then the server can either use another character encoding, or 1086 send a 406 (Not Acceptable) response. 1077 1087 </t> 1078 1088 </section> … … 1131 1141 </t> 1132 1142 <t> 1133 If an Accept-Encoding field is present in a request, and if the 1134 server cannot send a response which is acceptable according to the 1135 Accept-Encoding header field, then the server &SHOULD; send an error response 1136 with the 406 (Not Acceptable) status code. 1143 If an Accept-Encoding field is present in a request, but the server cannot 1144 send a response which is acceptable, then the server &SHOULD; send a 1145 response without any encoding (i.e., the "identity" encoding). 1137 1146 </t> 1138 1147 <t> … … 3011 3020 <section title="Since draft-ietf-httpbis-p3-payload-15" anchor="changes.since.15"> 3012 3021 <t> 3013 None yet. 3022 Closed issues: 3023 <list style="symbols"> 3024 <t> 3025 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>: 3026 "Strength of requirements on Accept re: 406" 3027 </t> 3028 </list> 3014 3029 </t> 3015 3030 </section>
Note: See TracChangeset
for help on using the changeset viewer.