Changeset 1495
- Timestamp:
- 18/12/11 12:35:13 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1494 r1495 359 359 } 360 360 @bottom-center { 361 content: "Expires June 18, 2012";361 content: "Expires June 20, 2012"; 362 362 } 363 363 @bottom-right { … … 411 411 <meta name="dct.creator" content="Reschke, J. F."> 412 412 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 413 <meta name="dct.issued" scheme="ISO8601" content="2011-12-1 6">413 <meta name="dct.issued" scheme="ISO8601" content="2011-12-18"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 415 415 <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."> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: June 18, 2012</td>444 <td class="left">Expires: June 20, 2012</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">December 1 6, 2011</td>497 <td class="right">December 18, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on June 18, 2012.</p>527 <p>This Internet-Draft will expire on June 20, 2012.</p> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 3004 3004 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>) 3005 3005 </p> 3006 <p id="rfc.section.A.p.11">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3006 <p id="rfc.section.A.p.11">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3007 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.3</a>) 3008 </p> 3009 <p id="rfc.section.A.p.12">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3007 3010 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3008 3011 (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.5</a>) 3009 3012 </p> 3010 <p id="rfc.section.A.p.1 2">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.6</a>)3011 </p> 3012 <p id="rfc.section.A.p.1 3">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.7</a>)3013 </p> 3014 <p id="rfc.section.A.p.1 4">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated3013 <p id="rfc.section.A.p.13">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.6</a>) 3014 </p> 3015 <p id="rfc.section.A.p.14">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.7</a>) 3016 </p> 3017 <p id="rfc.section.A.p.15">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3015 3018 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>) 3016 3019 </p> … … 3494 3497 </li> 3495 3498 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3496 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a> </li>3499 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3497 3500 <li>Expect Values 3498 3501 <ul> … … 3555 3558 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3556 3559 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li> 3557 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.h.4"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a> </li>3560 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.h.4"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3558 3561 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li> 3559 3562 <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.location.3">10.3</a>, <a href="#rfc.xref.header.location.4">A</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1494 r1495 4008 4008 </t> 4009 4009 <t> 4010 The ABNF for the Expect header field has been both fixed (allowing parameters 4011 for value-less expectations as well) and simplified (allowing trailing 4012 semicolons after "100-continue" when they were invalid before). 4013 (<xref target="header.expect"/>) 4014 </t> 4015 <t> 4010 4016 Correct syntax of Location header field to allow URI references (including 4011 4017 relative references and fragments), as referred symbol "absoluteURI" wasn't
Note: See TracChangeset
for help on using the changeset viewer.