Changeset 1536 for draft-ietf-httpbis/latest
- Timestamp:
- 16/02/12 22:26:09 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1534 r1536 460 460 } 461 461 @bottom-center { 462 content: "Expires August 1 1, 2012";462 content: "Expires August 19, 2012"; 463 463 } 464 464 @bottom-right { … … 512 512 <meta name="dct.creator" content="Reschke, J. F."> 513 513 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 514 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 08">514 <meta name="dct.issued" scheme="ISO8601" content="2012-02-16"> 515 515 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 516 516 <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."> … … 543 543 </tr> 544 544 <tr> 545 <td class="left">Expires: August 1 1, 2012</td>545 <td class="left">Expires: August 19, 2012</td> 546 546 <td class="right">HP</td> 547 547 </tr> … … 596 596 <tr> 597 597 <td class="left"></td> 598 <td class="right">February 8, 2012</td>598 <td class="right">February 16, 2012</td> 599 599 </tr> 600 600 </tbody> … … 626 626 in progress”. 627 627 </p> 628 <p>This Internet-Draft will expire on August 1 1, 2012.</p>628 <p>This Internet-Draft will expire on August 19, 2012.</p> 629 629 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 630 630 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 775 775 <li>11.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 776 776 <li>11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 777 <li>11.3 <a href="#location.spoofing ">Location Headers and Spoofing</a></li>777 <li>11.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 778 778 <li>11.4 <a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li> 779 779 </ul> … … 2343 2343 <div id="rfc.iref.h.6"></div> 2344 2344 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.location" href="#header.location">Location</a></h2> 2345 <p id="rfc.section.9.5.p.1">The "Location" header field is used to identify a newly created resource, or to redirect the recipient to a different location2346 for completion of the request.2347 < /p>2348 <p id="rfc.section.9.5.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,2345 <p id="rfc.section.9.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 2346 </p> 2347 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2348 </pre><p id="rfc.section.9.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2349 2349 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2350 2350 </p> 2351 <p id="rfc.section.9.5.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). 2352 </p> 2353 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2354 </pre><div id="rfc.figure.u.24"></div> 2355 <p>Examples are:</p> <pre class="text"> Location: http://www.example.org/pub/WWW/People.html#tim 2356 </pre><div id="rfc.figure.u.25"></div><pre class="text"> Location: /index.html 2357 </pre><div class="note" id="rfc.section.9.5.p.7"> 2351 <p id="rfc.section.9.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, 2352 then the original URI's fragment identifier is added to the final value. 2353 </p> 2354 <div id="rfc.figure.u.24"></div> 2355 <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim 2356 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2357 <div id="rfc.figure.u.25"></div> 2358 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2359 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2360 <div class="note" id="rfc.section.9.5.p.7"> 2358 2361 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2359 2362 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>). … … 2364 2367 </p> 2365 2368 <div class="note" id="rfc.section.9.5.p.9"> 2366 <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,2367 and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might2368 inconvenience anyone relying on the semantics of the original URI's fragment identifier.2369 </p>2370 </div>2371 <div class="note" id="rfc.section.9.5.p.10">2372 2369 <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.13"><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. 2373 2370 It is therefore possible for a response to contain header fields for both Location and Content-Location. … … 2904 2901 Such services can use POST-based form submission instead. 2905 2902 </p> 2906 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing " href="#location.spoofing">Location Headers and Spoofing</a></h2>2903 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> 2907 2904 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations 2908 2905 to make sure that they do not attempt to invalidate resources over which they have no authority. 2906 </p> 2907 <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak 2908 confidential information to the target server — although the fragment identifier is not transmitted in the final request, 2909 it might be visible to the user agent through other means, such as scripting. 2909 2910 </p> 2910 2911 <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a> Security Considerations for CONNECT … … 3491 3492 <ul> 3492 3493 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/238">http://tools.ietf.org/wg/httpbis/trac/ticket/238</a>>: "Requirements for user intervention during redirects" 3494 </li> 3495 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/295">http://tools.ietf.org/wg/httpbis/trac/ticket/295</a>>: "Applying original fragment to 'plain' redirected URI" 3493 3496 </li> 3494 3497 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/302">http://tools.ietf.org/wg/httpbis/trac/ticket/302</a>>: "Misplaced text on connection handling in p2" -
draft-ietf-httpbis/latest/p2-semantics.xml
r1534 r1536 2586 2586 <x:anchor-alias value="Location"/> 2587 2587 <t> 2588 The "Location" header field is used to identify a newly created 2589 resource, or to redirect the recipient to a different location for 2590 completion of the request. 2591 </t> 2588 The "Location" header field &MAY; be sent in responses to refer to 2589 a specific resource in accordance with the semantics of the status 2590 code. 2591 </t> 2592 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/> 2593 <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref> 2594 </artwork></figure> 2592 2595 <t> 2593 2596 For 201 (Created) responses, the Location is the URI of the new resource … … 2600 2603 of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>), 2601 2604 the final value is computed by resolving it against the effective request 2602 URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). 2603 </t> 2604 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/> 2605 <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>2606 </ artwork></figure>2605 URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). If the original URI, as 2606 navigated to by the user agent, did contain a fragment identifier, and the 2607 final value does not, then the original URI's fragment identifier is added 2608 to the final value. 2609 </t> 2607 2610 <figure> 2608 <preamble> Examples are:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->2611 <preamble>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc--> 2609 2612 <artwork type="example"> 2610 Location: http://www.example.org/pub/WWW/People.html#tim 2611 </artwork></figure><figure><artwork type="example"> Location: /index.html 2612 </artwork></figure> 2613 Location: /pub/WWW/People.html#tim 2614 </artwork> 2615 <postamble>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</postamble> 2616 </figure> 2617 <figure> 2618 <preamble>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc--> 2619 <artwork type="example"> 2620 Location: http://www.example.net/index.html 2621 </artwork> 2622 <postamble>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</postamble> 2623 </figure> 2613 2624 <x:note> 2614 2625 <t> … … 2624 2635 created resource. 2625 2636 </t> 2626 <x:note>2627 <t>2628 <x:h>Note:</x:h> This specification does not define precedence rules2629 for the case where the original URI, as navigated to by the user2630 agent, and the Location header field value both contain fragment2631 identifiers. Thus be aware that including fragment identifiers might2632 inconvenience anyone relying on the semantics of the original URI's2633 fragment identifier.2634 </t>2635 </x:note>2636 2637 <x:note> 2637 2638 <t> … … 3284 3285 </section> 3285 3286 3286 <section title="Location Header s and Spoofing" anchor="location.spoofing">3287 <section title="Location Header Fields: Spoofing and Information Leakage" anchor="location.spoofing-leakage"> 3287 3288 <t> 3288 3289 If a single server supports multiple organizations that do not trust … … 3291 3292 said organizations to make sure that they do not attempt to 3292 3293 invalidate resources over which they have no authority. 3294 </t> 3295 <t> 3296 Furthermore, appending the fragment identifier from one URI to another 3297 one obtained from a Location header field might leak confidential 3298 information to the target server — although the fragment identifier is 3299 not transmitted in the final request, it might be visible to the user agent 3300 through other means, such as scripting. 3293 3301 </t> 3294 3302 </section> … … 4658 4666 </t> 4659 4667 <t> 4668 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/295"/>: 4669 "Applying original fragment to 'plain' redirected URI" 4670 </t> 4671 <t> 4660 4672 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/302"/>: 4661 4673 "Misplaced text on connection handling in p2"
Note: See TracChangeset
for help on using the changeset viewer.