![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 2410 for draft-ietf-httpbis/latest
- Timestamp:
- 24/09/13 01:57:10 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (9 diffs)
-
p1-messaging.xml (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2406 r2410 446 446 } 447 447 @bottom-center { 448 content: "Expires March 2 0, 2014";448 content: "Expires March 27, 2014"; 449 449 } 450 450 @bottom-right { … … 488 488 <meta name="dct.creator" content="Reschke, J. F."> 489 489 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 490 <meta name="dct.issued" scheme="ISO8601" content="2013-09- 16">490 <meta name="dct.issued" scheme="ISO8601" content="2013-09-23"> 491 491 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">September 16, 2013</td>519 <td class="right">September 23, 2013</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: March 2 0, 2014</td>522 <td class="left">Expires: March 27, 2014</td> 523 523 <td class="right"></td> 524 524 </tr> … … 548 548 in progress”. 549 549 </p> 550 <p>This Internet-Draft will expire on March 2 0, 2014.</p>550 <p>This Internet-Draft will expire on March 27, 2014.</p> 551 551 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 552 552 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2215 2215 that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request. 2216 2216 </p> 2217 <p id="rfc.section.6.7.p.11">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch 2217 <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., 2218 the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response. 2219 </p> 2220 <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch 2218 2221 the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those 2219 purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.2 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2220 </p> 2221 <p id="rfc.section.6.7.p.1 2">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2222 purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2223 </p> 2224 <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2222 2225 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure 2223 2226 defined in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.5</a>. … … 2518 2521 <li>Pointer to specification text</li> 2519 2522 </ul> 2520 <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2. 29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2523 <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2521 2524 </p> 2522 2525 <p id="rfc.section.8.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this specification. … … 2656 2659 that most implementations will choose substantially higher limits. 2657 2660 </p> 2658 <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.3 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.2661 <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>. 2659 2662 </p> 2660 2663 <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods, … … 3462 3465 </li> 3463 3466 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3464 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29"> 8.4.1</a>, <a href="#rfc.xref.Part2.30">9.3</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>3467 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">8.4.1</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#rfc.xref.Part2.32">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul> 3465 3468 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3466 3469 <li><em>Section 3</em> <a href="#rfc.xref.Part2.15">3.3.2</a></li> 3467 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2. 29">8.4.1</a></li>3470 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">8.4.1</a></li> 3468 3471 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.23">5.7.2</a></li> 3469 3472 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> … … 3473 3476 <li><em>Section 4.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.20">5.3</a></li> 3474 3477 <li><em>Section 4.3.7</em> <a href="#rfc.xref.Part2.21">5.3</a></li> 3478 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part2.28">6.7</a></li> 3475 3479 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.18">4.3</a></li> 3476 3480 <li><em>Section 6</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li> 3477 3481 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.22">5.6</a></li> 3478 3482 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.24">5.7.2</a></li> 3479 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.2 8">6.7</a></li>3480 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.3 1">9.3</a></li>3481 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.3 0">9.3</a></li>3483 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.29">6.7</a></li> 3484 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.32">9.3</a></li> 3485 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">9.3</a></li> 3482 3486 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3483 3487 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2406 r2410 35 35 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 36 <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 38 <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 39 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 3286 3287 the listed protocols. A server &MUST; ignore an Upgrade header field that 3287 3288 is received in an HTTP/1.0 request. 3289 </t> 3290 <t> 3291 A client cannot begin using an upgraded protocol on the connection until 3292 it has completely sent the request message (i.e., the client can't change 3293 the protocol it is sending in the middle of a message). 3294 If a server receives both Upgrade and an <x:ref>Expect</x:ref> header field 3295 with the "100-continue" expectation (&header-expect;), the 3296 server &MUST; send a <x:ref>100 (Continue)</x:ref> response before sending 3297 a <x:ref>101 (Switching Protocols)</x:ref> response. 3288 3298 </t> 3289 3299 <t>
Note: See TracChangeset
for help on using the changeset viewer.
