Changeset 1707 for draft-ietf-httpbis/latest
- Timestamp:
- 03/07/12 17:25:39 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1706 r1707 818 818 <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and 819 819 for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the 820 case of security or privacy options) and also those where the software agent mayact autonomously.820 case of security or privacy options) and also those where the software agent can act autonomously. 821 821 </p> 822 822 </div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1706 r1707 313 313 user interface or interactive suggestions might be made, e.g., warning the 314 314 user or given the user an option in the case of security or privacy 315 options) and also those where the software agent mayact autonomously.315 options) and also those where the software agent can act autonomously. 316 316 </t> 317 317 </x:note> -
draft-ietf-httpbis/latest/p2-semantics.html
r1697 r1707 449 449 } 450 450 @bottom-center { 451 content: "Expires January 2, 2013";451 content: "Expires January 4, 2013"; 452 452 } 453 453 @bottom-right { … … 497 497 <meta name="dct.creator" content="Reschke, J. F."> 498 498 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 1">499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-03"> 500 500 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 501 501 <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. Furthermore, it defines HTTP message content, metadata, and content negotiation."> … … 528 528 </tr> 529 529 <tr> 530 <td class="left">Expires: January 2, 2013</td>530 <td class="left">Expires: January 4, 2013</td> 531 531 <td class="right">greenbytes</td> 532 532 </tr> 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">July 1, 2012</td>535 <td class="right">July 3, 2012</td> 536 536 </tr> 537 537 </tbody> … … 563 563 in progress”. 564 564 </p> 565 <p>This Internet-Draft will expire on January 2, 2013.</p>565 <p>This Internet-Draft will expire on January 4, 2013.</p> 566 566 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 567 567 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 941 941 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 942 942 </p> 943 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used944 to satisfy a subsequent request.943 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular under what conditions a cache can store the response, and under what conditions such a stored response can 944 be used to satisfy a subsequent request. 945 945 </p> 946 946 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> … … 1153 1153 to reject the request. 1154 1154 </p> 1155 <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data maybe discarded1156 if the eventual response is negative, and the connection maybe reset with no response if more than one TCP segment is outstanding.1155 <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1156 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1157 1157 </p> 1158 1158 <p id="rfc.section.2.3.8.p.10">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, … … 1230 1230 </li> 1231 1231 <li> 1232 <p>Whether the header field shouldbe preserved across redirects.</p>1232 <p>Whether the header field ought to be preserved across redirects.</p> 1233 1233 </li> 1234 1234 </ul> … … 1861 1861 <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI 1862 1862 in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy 1863 the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which mayitself be redirected further,1863 the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, 1864 1864 and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is 1865 1865 not considered equivalent to the effective request URI. -
draft-ietf-httpbis/latest/p2-semantics.xml
r1697 r1707 489 489 and whether they are idempotent (<xref target="idempotent.methods"/>). 490 490 They also need to state whether they can be cached (&caching;); in 491 particular what conditions a cache may store the response, and under what492 conditions such a stored response maybe used to satisfy a subsequent491 particular under what conditions a cache can store the response, and under 492 what conditions such a stored response can be used to satisfy a subsequent 493 493 request. 494 494 </t> … … 931 931 to server &MAY; be sent immediately after the request (before a response 932 932 is received). The usual caveats also apply: 933 data maybe discarded if the eventual response is negative, and the934 connection maybe reset with no response if more than one TCP segment933 data can be discarded if the eventual response is negative, and the 934 connection can be reset with no response if more than one TCP segment 935 935 is outstanding. 936 936 </t> … … 1044 1044 <x:lt><t>Whether the header field is useful or allowable in trailers (see 1045 1045 &chunked-encoding;).</t></x:lt> 1046 <x:lt><t>Whether the header field shouldbe preserved across redirects.</t></x:lt>1046 <x:lt><t>Whether the header field ought to be preserved across redirects.</t></x:lt> 1047 1047 </list> 1048 1048 </t> … … 1675 1675 request, a user agent &SHOULD; perform a retrieval request using the 1676 1676 Location URI (a GET or HEAD request if using HTTP), which 1677 mayitself be redirected further, and present the eventual result as an1677 can itself be redirected further, and present the eventual result as an 1678 1678 answer to the original request. 1679 1679 Note that the new URI in the Location header field is not considered -
draft-ietf-httpbis/latest/p6-cache.html
r1702 r1707 1447 1447 <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive. 1448 1448 We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the 1449 community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise1450 private response in their shared cache(s) could do so by including1449 community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to 1450 use an otherwise private response in their shared cache(s) could do so by including 1451 1451 </p> 1452 1452 <div id="rfc.figure.u.10"></div><pre class="text"> Cache-Control: private, community="UCI" -
draft-ietf-httpbis/latest/p6-cache.xml
r1702 r1707 1611 1611 this new directive to mean that, in addition to any private cache, any 1612 1612 cache that is shared only by members of the community named within its 1613 value may cache the response. An origin server wishing to allow the UCI1614 community to use an otherwise private response in their shared cache(s)1615 c ould do so by including1613 value is allowed to cache the response. An origin server wishing to allow 1614 the UCI community to use an otherwise private response in their shared 1615 cache(s) could do so by including 1616 1616 </t> 1617 1617 <figure><artwork type="example">
Note: See TracChangeset
for help on using the changeset viewer.