Changeset 1463 for draft-ietf-httpbis
- Timestamp:
- 31/10/11 02:36:49 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1458 r1463 359 359 } 360 360 @bottom-center { 361 content: "Expires April 29, 2012";361 content: "Expires May 3, 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-10- 27">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-31"> 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, hypertext 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: April 29, 2012</td>442 <td class="left">Expires: May 3, 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">October 27, 2011</td>495 <td class="right">October 31, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on April 29, 2012.</p>525 <p>This Internet-Draft will expire on May 3, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 877 877 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 878 878 </pre><p id="rfc.section.3.1.p.7">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 879 parser components. Also, the meaning of a value ought to be independent of the syntax variant used for it (for an example,880 see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).879 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 880 it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 881 881 </p> 882 882 <p id="rfc.section.3.1.p.8">Authors of specifications defining new header fields are advised to consider documenting: </p> … … 885 885 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>). 886 886 </p> 887 <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default888 would be to ignore the header field, but this might not always be the right choice).887 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible 888 default would be to ignore the header field, but this might not always be the right choice). 889 889 </p> 890 <p> Furthermore, intermediaries and software libraries might combine multiple header field instances into a single one, despite891 theheader field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type",890 <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the 891 header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type", 892 892 as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI). 893 893 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1458 r1463 545 545 parameters (for instance, Content-Type, defined in &header-content-type;). 546 546 Allowing both unquoted (token) and quoted (quoted-string) syntax for the 547 parameter value enables recipients to use existing parser components. Also,548 the meaning of a value ought to be independent of the syntax variant used549 for it (for an example, see the notes on parameter handling for media types550 in &media-types;).547 parameter value enables recipients to use existing parser components. When 548 allowing both forms, the meaning of a parameter value ought to be 549 independent of the syntax used for it (for an example, see the notes on 550 parameter handling for media types in &media-types;). 551 551 </t> 552 552 <t> … … 557 557 <t>Whether the field is a single value, or whether it can be a list 558 558 (delimited by commas; see &header-fields;).</t> 559 <t>If it does not use the list syntax, how to treat messages where the 560 header field occurs multiple times (a sensible default would be to ignore 561 the header field, but this might not always be the right choice).</t> 562 <t>Furthermore, intermediaries and software libraries might combine 559 <t>If it does not use the list syntax, document how to treat messages 560 where the header field occurs multiple times (a sensible default would 561 be to ignore the header field, but this might not always be the right 562 choice).</t> 563 <t>Note that intermediaries and software libraries might combine 563 564 multiple header field instances into a single one, despite the header 564 565 field not allowing this. A robust format enables recipients to discover
Note: See TracChangeset
for help on using the changeset viewer.