Changeset 1496
- Timestamp:
- 20/12/11 10:40:00 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1495 r1496 359 359 } 360 360 @bottom-center { 361 content: "Expires June 2 0, 2012";361 content: "Expires June 22, 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- 18">413 <meta name="dct.issued" scheme="ISO8601" content="2011-12-20"> 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 2 0, 2012</td>444 <td class="left">Expires: June 22, 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 18, 2011</td>497 <td class="right">December 20, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on June 2 0, 2012.</p>527 <p>This Internet-Draft will expire on June 22, 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> … … 2293 2293 <p>Examples are:</p> <pre class="text"> Location: http://www.example.org/pub/WWW/People.html#tim 2294 2294 </pre><div id="rfc.figure.u.25"></div><pre class="text"> Location: /index.html 2295 </pre><p id="rfc.section.9.5.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2295 </pre><div class="note" id="rfc.section.9.5.p.7"> 2296 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2297 or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.1</a>). 2298 </p> 2299 </div> 2300 <p id="rfc.section.9.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2296 2301 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2297 2302 </p> 2298 <div class="note" id="rfc.section.9.5.p. 8">2303 <div class="note" id="rfc.section.9.5.p.9"> 2299 2304 <p> <b>Note:</b> This specification does not define precedence rules for the case where the original URI, as navigated to by the user agent, 2300 2305 and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might … … 2302 2307 </p> 2303 2308 </div> 2304 <div class="note" id="rfc.section.9.5.p. 9">2309 <div class="note" id="rfc.section.9.5.p.10"> 2305 2310 <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.12"><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. 2306 2311 It is therefore possible for a response to contain header fields for both Location and Content-Location. … … 3411 3416 <p id="rfc.section.C.19.p.1">Closed issues: </p> 3412 3417 <ul> 3418 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header payload handling" 3419 </li> 3413 3420 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>>: "Clarify status code for rate limiting" (change backed out because a new status code is being defined for this purpose) 3414 3421 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1495 r1496 2709 2709 </artwork></figure><figure><artwork type="example"> Location: /index.html 2710 2710 </artwork></figure> 2711 <x:note> 2712 <t> 2713 <x:h>Note:</x:h> Some recipients attempt to recover from Location fields 2714 that are not valid URI references. This specification does not mandate or 2715 define such processing, but does allow it (see <xref target="intro.conformance.and.error.handling"/>). 2716 </t> 2717 </x:note> 2711 2718 <t> 2712 2719 There are circumstances in which a fragment identifier in a Location URI … … 4712 4719 <list style="symbols"> 4713 4720 <t> 4721 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>: 4722 "Location header payload handling" 4723 </t> 4724 <t> 4714 4725 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>: 4715 4726 "Clarify status code for rate limiting" (change backed out because
Note: See TracChangeset
for help on using the changeset viewer.