Changeset 2436
- Timestamp:
- 28/10/13 10:34:58 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2434 r2436 445 445 } 446 446 @bottom-center { 447 content: "Expires April 30, 2014";447 content: "Expires May 1, 2014"; 448 448 } 449 449 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2013-10-2 7">492 <meta name="dct.issued" scheme="ISO8601" content="2013-10-28"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 518 518 <tr> 519 519 <td class="left">Intended status: Standards Track</td> 520 <td class="right">October 2 7, 2013</td>520 <td class="right">October 28, 2013</td> 521 521 </tr> 522 522 <tr> 523 <td class="left">Expires: April 30, 2014</td>523 <td class="left">Expires: May 1, 2014</td> 524 524 <td class="right"></td> 525 525 </tr> … … 550 550 in progress”. 551 551 </p> 552 <p>This Internet-Draft will expire on April 30, 2014.</p>552 <p>This Internet-Draft will expire on May 1, 2014.</p> 553 553 </div> 554 554 <div id="rfc.copyrightnotice"> … … 3833 3833 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3834 3834 </p> 3835 <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name 3835 <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. 3836 </p> 3837 <p id="rfc.section.8.3.1.p.3">Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name 3836 3838 with "X-" unless the header field will never be used on the Internet. (The "x-" prefix idiom has been extensively misused 3837 3839 in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet 3838 processing, since the prefix would ensure that private names never collide with a newly registered Internet name .)3839 </p> 3840 <p id="rfc.section.8.3.1.p. 3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3840 processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see <a href="#BCP178" id="rfc.xref.BCP178.1"><cite title="Deprecating the "X-" Prefix and Similar Constructs in Application Protocols">[BCP178]</cite></a> for further information) 3841 </p> 3842 <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3841 3843 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 3842 3844 </p> 3843 <p id="rfc.section.8.3.1.p. 4">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such3845 <p id="rfc.section.8.3.1.p.5">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such 3844 3846 as quoted-string. 3845 3847 </p> 3846 <p id="rfc.section.8.3.1.p. 5">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed3848 <p id="rfc.section.8.3.1.p.6">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 3847 3849 in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string 3848 3850 ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3849 3851 </p> 3850 <p id="rfc.section.8.3.1.p. 6">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like3852 <p id="rfc.section.8.3.1.p.7">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like 3851 3853 these: 3852 3854 </p> … … 3854 3856 "http://without-a-comma.example.com/" 3855 3857 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 3856 </pre><p id="rfc.section.8.3.1.p. 8">Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside3858 </pre><p id="rfc.section.8.3.1.p.9">Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside 3857 3859 double-quotes will likely cause unnecessary confusion. 3858 3860 </p> 3859 <p id="rfc.section.8.3.1.p. 9">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing3861 <p id="rfc.section.8.3.1.p.10">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3.1.1.5</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 3860 3862 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 3861 3863 it (for an example, see the notes on parameter handling for media types in <a href="#media.type" title="Media Type">Section 3.1.1.1</a>). 3862 3864 </p> 3863 <p id="rfc.section.8.3.1.p.1 0">Authors of specifications defining new header fields are advised to consider documenting: </p>3865 <p id="rfc.section.8.3.1.p.11">Authors of specifications defining new header fields are advised to consider documenting: </p> 3864 3866 <ul> 3865 3867 <li> … … 4338 4340 <td class="reference"><b id="BCP13">[BCP13]</b></td> 4339 4341 <td class="top"><a href="mailto:ned+ietf@mrochek.com" title="Oracle">Freed, N.</a>, <a href="mailto:john+ietf@jck.com">Klensin, J.</a>, and <a href="mailto:tony+mtsuffix@maillennium.att.com" title="AT&T Laboratories">T. Hansen</a>, “<a href="http://tools.ietf.org/html/rfc6838">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 6838, January 2013. 4342 </td> 4343 </tr> 4344 <tr> 4345 <td class="reference"><b id="BCP178">[BCP178]</b></td> 4346 <td class="top">Saint-Andre, P., Crocker, D., and M. Nottingham, “<a href="http://tools.ietf.org/html/rfc6648">Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</a>”, BCP 178, RFC 6648, June 2012. 4340 4347 </td> 4341 4348 </tr> … … 4766 4773 </li> 4767 4774 </ul> 4775 <p id="rfc.section.E.2.p.2">Partly resolved issues: </p> 4776 <ul> 4777 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/503">http://tools.ietf.org/wg/httpbis/trac/ticket/503</a>>: "APPSDIR review of draft-ietf-httpbis-p2-semantics-24" 4778 </li> 4779 </ul> 4768 4780 </div> 4769 4781 </div> … … 4840 4852 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 4841 4853 <li><em>BCP13</em> <a href="#rfc.xref.BCP13.1">3.1.1.1</a>, <a href="#BCP13"><b>11.2</b></a></li> 4854 <li><em>BCP178</em> <a href="#rfc.xref.BCP178.1">8.3.1</a>, <a href="#BCP178"><b>11.2</b></a></li> 4842 4855 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">8.3</a>, <a href="#rfc.xref.BCP90.2">8.3.1</a>, <a href="#BCP90"><b>11.2</b></a></li> 4843 4856 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2434 r2436 4606 4606 <t> 4607 4607 The requirements for header field names are defined in 4608 <xref target="BCP90"/>. Authors of specifications defining new fields are 4608 <xref target="BCP90"/>. 4609 </t> 4610 <t> 4611 Authors of specifications defining new fields are 4609 4612 advised to keep the name as short as practical and to not prefix the name 4610 4613 with "X-" unless the header field will never be used on the Internet. … … 4612 4615 intended to only be used as a mechanism for avoiding name collisions inside 4613 4616 proprietary software or intranet processing, since the prefix would ensure 4614 that private names never collide with a newly registered Internet name.) 4617 that private names never collide with a newly registered Internet name; see 4618 <xref target="BCP178"/> for further information) 4615 4619 </t> 4616 4620 <t> … … 5800 5804 </reference> 5801 5805 5806 <reference anchor="BCP178"> 5807 <front> 5808 <title>Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</title> 5809 <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre"/> 5810 <author initials="D." surname="Crocker" fullname="Dave Crocker"/> 5811 <author initials="M." surname="Nottingham" fullname="Mark Nottingham"/> 5812 <date year="2012" month="June"/> 5813 </front> 5814 <seriesInfo name="BCP" value="178"/> 5815 <seriesInfo name="RFC" value="6648"/> 5816 </reference> 5817 5802 5818 <reference anchor="status-308"> 5803 5819 <front> … … 6319 6335 </list> 6320 6336 </t> 6337 <t> 6338 Partly resolved issues: 6339 <list style="symbols"> 6340 <t> 6341 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/503"/>: 6342 "APPSDIR review of draft-ietf-httpbis-p2-semantics-24" 6343 </t> 6344 </list> 6345 </t> 6321 6346 </section> 6322 6347 </section>
Note: See TracChangeset
for help on using the changeset viewer.