Ignore:
Timestamp:
Aug 2, 2010, 6:20:54 AM (9 years ago)
Author:
julian.reschke@…
Message:

lowercase "effective request URI" throughout, use "target resource" instead of "resource identified by the effective request URI" where possible.

Location:
draft-ietf-httpbis/latest
Files:
12 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r971 r972  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: February 2, 2011</td>
     437               <td class="left">Expires: February 3, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">August 1, 2010</td>
     490               <td class="right">August 2, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on February 2, 2011.</p>
     518      <p>This Internet-Draft will expire on February 3, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    14341434         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
    14351435      </ul>
    1436       <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>
     1436      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the effective Request URI is undefined.</p>
    14371437      <div id="rfc.figure.u.40"></div>
    14381438      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r971 r972  
    17091709</t>
    17101710<t>
    1711    Otherwise, when request-target uses the authority form, the Effective
     1711   Otherwise, when request-target uses the authority form, the effective
    17121712   Request URI is undefined.
    17131713</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r971 r972  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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 &#34;HTTP/1.1&#34; 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.">
     
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: February 2, 2011</td>
     436               <td class="left">Expires: February 3, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
     
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">August 1, 2010</td>
     489               <td class="right">August 2, 2010</td>
    490490            </tr>
    491491         </tbody>
     
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire on February 2, 2011.</p>
     516      <p>This Internet-Draft will expire on February 3, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    753753             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
    754754</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    755       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     755      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    756756      </p>
    757757      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
     
    881881      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    882882      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
    883          Status-Line. These header fields give information about the server and about further access to the resource identified by
    884          the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>).
     883         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>).
    885884      </p>
    886885      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
     
    909908      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    910909      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    911       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     910      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    912911         rules are used (with the first applicable one being selected):
    913912      </p>
    914913      <ol>
    915914         <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the
    916             resource identified by the effective request URI.
     915            target resource.
    917916         </li>
    918917         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
    919             representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     918            representation of the target (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    920919         </li>
    921920         <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
    922             is a representation of the resource identified by the effective request URI.
     921            is a representation of the target resource.
    923922         </li>
    924923         <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
     
    984983      <div id="rfc.iref.g.8"></div>
    985984      <div id="rfc.iref.m.2"></div>
    986       <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
    987          identified by the effective request URI.
    988       </p>
    989       <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
     985      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the target resource.</p>
     986      <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
    990987         in the response and not the source text of the process, unless that text happens to be the output of the process.
    991988      </p>
     
    10191016      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    10201017      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
    1021          processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the
    1022          following functions:
     1018         processed by the target resource. POST is designed to allow a uniform method to cover the following functions:
    10231019      </p>
    10241020      <ul>
     
    10381034         a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    10391035      </p>
    1040       <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1036      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10411037      </p>
    10421038      <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
     
    10541050         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10551051      </p>
    1056       <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1052      <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    10571053      </p>
    10581054      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
     
    10751071      <div id="rfc.iref.m.6"></div>
    10761072      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
    1077       <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
     1073      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
    10781074         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    10791075         successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
     
    11451141      <dl>
    11461142         <dt>GET</dt>
    1147          <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd>
     1143         <dd>a representation of the target resource is sent in the response;</dd>
    11481144         <dt>HEAD</dt>
    11491145         <dd>the same representation as GET, except without the message-body;</dd>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r971 r972  
    433433  <x:anchor-alias value="extension-method"/>
    434434<t>
    435    The Method token indicates the method to be performed on the resource
    436    identified by the effective request URI (&effective-request-uri;). The
    437    method is case-sensitive.
     435   The Method token indicates the method to be performed on the target
     436   resource (&effective-request-uri;). The method is case-sensitive.
    438437</t>
    439438<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
     
    634633   information about the response which cannot be placed in the Status-Line.
    635634   These header fields give information about the server and about
    636    further access to the resource identified by the effective request URI
    637    (&effective-request-uri;).
     635   further access to the target resource (&effective-request-uri;).
    638636</t>
    639637<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/>
     
    684682</t>
    685683<t>
    686    In the common case, an HTTP response is a representation of the resource
    687    located at the effective request URI (see &effective-request-uri;). However,
    688    this is not always the case. To determine the URI of the resource a
    689    response is associated with, the following rules are used (with the first
    690    applicable one being selected):
     684   In the common case, an HTTP response is a representation of the target
     685   resource (see &effective-request-uri;). However, this is not always the
     686   case. To determine the URI of the resource a response is associated with,
     687   the following rules are used (with the first applicable one being selected):
    691688</t>
    692689<t><list style="numbers">
    693690   <t>If the response status code is 200 or 203 and the request method was GET,
    694    the response payload is a representation of the resource identified by the effective request URI.</t>
     691   the response payload is a representation of the target resource.</t>
    695692   <t>If the response status code is 204, 206, or 304 and the request method was GET
    696    or HEAD, the response payload is a partial representation of the resource identified
    697    by the effective request URI (see &caching-combining-headers;).</t>
     693   or HEAD, the response payload is a partial representation of the target
     694   (see &caching-combining-headers;).</t>
    698695   <t>If the response has a Content-Location header, and that URI is the same
    699696   as the effective request URI, the response payload is a representation of the
    700    resource identified by the effective request URI.</t>
     697   target resource.</t>
    701698   <t>If the response has a Content-Location header, and that URI is not the
    702699   same as the effective request URI, then the response asserts that its
     
    833830<t>
    834831   The GET method means retrieve whatever information (in the form of a
    835    representation) currently corresponds to the resource identified by the
    836    effective request URI.
     832   representation) currently corresponds to the target resource.
    837833</t>
    838834<t>   
    839    If the effective request URI identifies a data-producing process, it is the
     835   If the target resource is a data-producing process, it is the
    840836   produced data which shall be returned as the representation in the response and not
    841837   the source text of the process, unless that text happens to be the output of
     
    901897<t>
    902898   The POST method is used to request that the origin server accept the
    903    representation enclosed in the request as data to be processed by the resource
    904    identified by the effective request URI. POST is designed
    905    to allow a uniform method to cover the following functions:
     899   representation enclosed in the request as data to be processed by the
     900   target resource. POST is designed to allow a uniform method to cover the
     901   following functions:
    906902  <list style="symbols">
    907903    <t>
     
    942938   include explicit freshness information (see &p6-explicit;). A
    943939   cached POST response with a Content-Location header
    944    (see &header-content-location;) whose value is the Effective
     940   (see &header-content-location;) whose value is the effective
    945941   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
    946942</t>
     
    972968</t>
    973969<t>   
    974    If the resource identified by the effective request URI could not be
    975    created or modified, an appropriate error response &SHOULD; be given
    976    that reflects the nature of the problem.
     970   If the target resource could not be created or modified, an appropriate
     971   error response &SHOULD; be given that reflects the nature of the problem.
    977972   The recipient of the representation &MUST-NOT; ignore any Content-*
    978973   headers (headers starting with the prefix "Content-") that it does
     
    10241019  <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
    10251020<t>
    1026    The DELETE method requests that the origin server delete the resource
    1027    identified by the effective request URI. This method &MAY; be overridden by
     1021   The DELETE method requests that the origin server delete the target
     1022   resource. This method &MAY; be overridden by
    10281023   human intervention (or other means) on the origin server. The client cannot
    10291024   be guaranteed that the operation has been carried out, even if the
     
    11711166  <list style="hanging">
    11721167    <t hangText="GET">
    1173           a representation of the resource corresponding to the effective
    1174           request URI is sent in the response;
     1168          a representation of the target resource is sent in the response;
    11751169    </t>
    11761170    <t hangText="HEAD">
  • draft-ietf-httpbis/latest/p3-payload.html

    r971 r972  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: February 2, 2011</td>
     430               <td class="left">Expires: February 3, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    485485            <tr>
    486486               <td class="left"></td>
    487                <td class="right">August 1, 2010</td>
     487               <td class="right">August 2, 2010</td>
    488488            </tr>
    489489         </tbody>
     
    511511         in progress”.
    512512      </p>
    513       <p>This Internet-Draft will expire on February 2, 2011.</p>
     513      <p>This Internet-Draft will expire on February 3, 2011.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    12711271  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12721272                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1273 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1273</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    12741274         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    12751275      </p>
  • draft-ietf-httpbis/latest/p3-payload.xml

    r971 r972  
    14311431</artwork></figure>
    14321432<t>
    1433    The Content-Location value is not a replacement for the Effective
     1433   The Content-Location value is not a replacement for the effective
    14341434   Request URI (&effective-request-uri;).  It is representation metadata.
    14351435   It has the same syntax and semantics as the header field of the same name
  • draft-ietf-httpbis/latest/p4-conditional.html

    r971 r972  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: February 2, 2011</td>
     428               <td class="left">Expires: February 3, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
     
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">August 1, 2010</td>
     485               <td class="right">August 2, 2010</td>
    486486            </tr>
    487487         </tbody>
     
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on February 2, 2011.</p>
     511      <p>This Internet-Draft will expire on February 3, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    896896      <div id="rfc.iref.h.1"></div>
    897897      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    898       <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local
    899          identifier for differentiating between representations of the same resource that vary over time or via content negotiation
    900          (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
     898      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating
     899         between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    901900      </p>
    902901      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#header.etag" class="smpl">ETag</a>   = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r971 r972  
    734734   The "ETag" response-header field provides the current value of the
    735735   entity-tag (see <xref target="entity.tags"/>) for one representation of
    736    the resource identified by the effective request URI.  An entity-tag
     736   the target resource.  An entity-tag
    737737   is intended for use as a resource-local identifier for differentiating
    738738   between representations of the same resource that vary over time or via
  • draft-ietf-httpbis/latest/p5-range.html

    r971 r972  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
     
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: February 2, 2011</td>
     428               <td class="left">Expires: February 3, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
     
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">August 1, 2010</td>
     485               <td class="right">August 2, 2010</td>
    486486            </tr>
    487487         </tbody>
     
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on February 2, 2011.</p>
     511      <p>This Internet-Draft will expire on February 3, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p6-cache.html

    r971 r972  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: February 2, 2011</td>
     430               <td class="left">Expires: February 3, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">August 1, 2010</td>
     491               <td class="right">August 2, 2010</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on February 2, 2011.</p>
     517      <p>This Internet-Draft will expire on February 3, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    938938      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
    939939      </p>
    940       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present):
     940      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present):
    941941      </p>
    942942      <ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r971 r972  
    854854</t>
    855855<t>
    856    The following HTTP methods &MUST; cause a cache to invalidate the Effective
     856   The following HTTP methods &MUST; cause a cache to invalidate the effective
    857857   Request URI (&effective-request-uri;) as well as the URI(s) in the Location
    858858   and Content-Location headers (if present):
  • draft-ietf-httpbis/latest/p7-auth.html

    r971 r972  
    393393      <meta name="dct.creator" content="Reschke, J. F.">
    394394      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    395       <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
     395      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
    396396      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    397397      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
     
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: February 2, 2011</td>
     426               <td class="left">Expires: February 3, 2011</td>
    427427               <td class="right">HP</td>
    428428            </tr>
     
    477477            <tr>
    478478               <td class="left"></td>
    479                <td class="right">August 1, 2010</td>
     479               <td class="right">August 2, 2010</td>
    480480            </tr>
    481481         </tbody>
     
    503503         in progress”.
    504504      </p>
    505       <p>This Internet-Draft will expire on February 2, 2011.</p>
     505      <p>This Internet-Draft will expire on February 3, 2011.</p>
    506506      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    507507      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.