Changeset 767


Ignore:
Timestamp:
Mar 3, 2010, 8:14:02 AM (10 years ago)
Author:
julian.reschke@…
Message:

assign stable anchors to all <cref> elements

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

Legend:

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

    r764 r767  
    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-03-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-03-03">
    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: September 2, 2010</td>
     437               <td class="left">Expires: September 4, 2010</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">March 1, 2010</td>
     490               <td class="right">March 3, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    520520      <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
    521521      </p>
    522       <p>This Internet-Draft will expire in September 2, 2010.</p>
     522      <p>This Internet-Draft will expire in September 4, 2010.</p>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    11011101   http://EXAMPLE.com/%7Esmith/home.html
    11021102   http://EXAMPLE.com:/%7esmith/home.html
    1103 </pre><p id="rfc.section.2.6.3.p.5"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: [[This paragraph does not belong here. --Roy]]]</span> If path-abempty is the empty string (i.e., there is no slash "/" path separator following the authority), then the "http"
     1103</pre><p id="rfc.section.2.6.3.p.5"> <span class="comment" id="TODO-not-here">[<a href="#TODO-not-here" class="smpl">TODO-not-here</a>: This paragraph does not belong here. --roy]</span> If path-abempty is the empty string (i.e., there is no slash "/" path separator following the authority), then the "http"
    11041104         URI <em class="bcp14">MUST</em> be given as "/" when used as a request-target (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    11051105      </p>
     
    18381838      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that may disappear</a></h1>
    18391839      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2>
    1840       <p id="rfc.section.8.1.p.1"> <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: TBS: describe why aliases like webcal are harmful.]</span>
     1840      <p id="rfc.section.8.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span>
    18411841      </p>
    18421842      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2>
    1843       <p id="rfc.section.8.2.p.1"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: TBD: Configured to use HTTP to proxy HTTP or other protocols.]</span>
     1843      <p id="rfc.section.8.2.p.1"> <span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span>
    18441844      </p>
    18451845      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2>
    1846       <p id="rfc.section.8.3.p.1"> <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: TBD: Interception of HTTP traffic for initiating access control.]</span>
     1846      <p id="rfc.section.8.3.p.1"> <span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span>
    18471847      </p>
    18481848      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2>
    1849       <p id="rfc.section.8.4.p.1"> <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: TBD: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span>
     1849      <p id="rfc.section.8.4.p.1"> <span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span>
    18501850      </p>
    18511851      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2>
    1852       <p id="rfc.section.8.5.p.1"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TBD: Instructions on composing HTTP requests via hypertext formats.]</span>
     1852      <p id="rfc.section.8.5.p.1"> <span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span>
    18531853      </p>
    18541854      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r764 r767  
    10211021</artwork></figure>
    10221022<t>
    1023    <cref>[[This paragraph does not belong here. --Roy]]</cref>
     1023   <cref anchor="TODO-not-here" source="roy">This paragraph does not belong here.</cref>
    10241024   If path-abempty is the empty string (i.e., there is no slash "/"
    10251025   path separator following the authority), then the "http" URI
     
    25232523<section title="Scheme aliases considered harmful" anchor="scheme.aliases">
    25242524<t>
    2525    <cref>TBS: describe why aliases like webcal are harmful.</cref>
     2525   <cref anchor="TBD-aliases-harmful">describe why aliases like webcal are harmful.</cref>
    25262526</t>
    25272527</section>
     
    25292529<section title="Use of HTTP for proxy communication" anchor="http.proxy">
    25302530<t>
    2531    <cref>TBD: Configured to use HTTP to proxy HTTP or other protocols.</cref>
     2531   <cref anchor="TBD-proxy-other">Configured to use HTTP to proxy HTTP or other protocols.</cref>
    25322532</t>
    25332533</section>
     
    25352535<section title="Interception of HTTP for access control" anchor="http.intercept">
    25362536<t>
    2537    <cref>TBD: Interception of HTTP traffic for initiating access control.</cref>
     2537   <cref anchor="TBD-intercept">Interception of HTTP traffic for initiating access control.</cref>
    25382538</t>
    25392539</section>
     
    25412541<section title="Use of HTTP by other protocols" anchor="http.others">
    25422542<t>
    2543    <cref>TBD: Profiles of HTTP defined by other protocol.
     2543   <cref anchor="TBD-profiles">Profiles of HTTP defined by other protocol.
    25442544   Extensions of HTTP like WebDAV.</cref>
    25452545</t>
     
    25482548<section title="Use of HTTP by media type specification" anchor="http.media">
    25492549<t>
    2550    <cref>TBD: Instructions on composing HTTP requests via hypertext formats.</cref>
     2550   <cref anchor="TBD-hypertext">Instructions on composing HTTP requests via hypertext formats.</cref>
    25512551</t>
    25522552</section>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r764 r767  
    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-03-01">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-03-03">
    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: September 2, 2010</td>
     436               <td class="left">Expires: September 4, 2010</td>
    437437               <td class="right">HP</td>
    438438            </tr>
     
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">March 1, 2010</td>
     489               <td class="right">March 3, 2010</td>
    490490            </tr>
    491491         </tbody>
     
    518518      <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
    519519      </p>
    520       <p>This Internet-Draft will expire in September 2, 2010.</p>
     520      <p>This Internet-Draft will expire in September 4, 2010.</p>
    521521      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    522522      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    920920            of the resource at the request-URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    921921         </li>
    922          <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI.
     922         <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="TODO-missref-requri">[<a href="#TODO-missref-requri" class="smpl">TODO-missref-requri</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI.
    923923         </li>
    924924         <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r764 r767  
    681681   request-URI (see &caching-combining-headers;).</t>
    682682   <t>If the response has a Content-Location header, and that URI is the same
    683    as the request-URI <cref>(see [ref])</cref>, the response is a representation of the
     683   as the request-URI <cref anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the
    684684   resource at the request-URI.</t>
    685685   <t>If the response has a Content-Location header, and that URI is not the
  • draft-ietf-httpbis/latest/p6-cache.html

    r766 r767  
    781781      <p id="rfc.section.2.2.p.2"> <span class="comment" id="TODO-method-cacheability">[<a href="#TODO-method-cacheability" class="smpl">TODO-method-cacheability</a>: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
    782782      </p>
    783       <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: DISCUSS: this currently includes successfully validated responses.]</span>
     783      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="DISCUSS-includes-validated">[<a href="#DISCUSS-includes-validated" class="smpl">DISCUSS-includes-validated</a>: this currently includes successfully validated responses.]</span>
    784784      </p>
    785785      <p id="rfc.section.2.2.p.4">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., a cache must not reply to such a request before having forwarded
     
    802802      </p>
    803803      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    804          This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: This wording may cause confusion, because the response may still be served stale.]</span>
     804         This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording may cause confusion, because the response may still be served stale.]</span>
    805805      </p>
    806806      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
     
    816816         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
    817817      </p>
    818       <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     818      <p id="rfc.section.2.3.p.8"> <span class="comment" id="ISSUE-no-req-for-directives">[<a href="#ISSUE-no-req-for-directives" class="smpl">ISSUE-no-req-for-directives</a>: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    819819      </p>
    820820      <p id="rfc.section.2.3.p.9">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     
    843843      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    844844      </p>
    845       <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
     845      <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="REVIEW-query-string-heuristics">[<a href="#REVIEW-query-string-heuristics" class="smpl">REVIEW-query-string-heuristics</a>: took away HTTP/1.0 query string heuristic uncacheability.]</span>
    846846      </p>
    847847      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
     
    919919      </p>
    920920      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    921          request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span>
     921         request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="TODO-req-missing">[<a href="#TODO-req-missing" class="smpl">TODO-req-missing</a>: Should there be a requirement here?]</span>
    922922      </p>
    923923      <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     
    936936         attacks.
    937937      </p>
    938       <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>
     938      <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span>
    939939      </p>
    940940      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
     
    946946         change at the origin server might not have gone through the cache where a response is stored.
    947947      </p>
    948       <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     948      <p id="rfc.section.2.5.p.8"> <span class="comment" id="TODO-spec-success-invalidate">[<a href="#TODO-spec-success-invalidate" class="smpl">TODO-spec-success-invalidate</a>: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    949949      </p>
    950950      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
     
    953953      </p>
    954954      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    955          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
     955         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    956956         name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    957957      </p>
     
    968968         be used to satisfy the request.
    969969      </p>
    970       <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span>
     970      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: may need language about Content-Location here]</span><span class="comment" id="TODO-inm-mult-etags">[<a href="#TODO-inm-mult-etags" class="smpl">TODO-inm-mult-etags</a>: cover case where INM with multiple etags was sent]</span>
    971971      </p>
    972972      <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     
    983983      <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
    984984      </p>
    985       <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
    986       </p>
    987       <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span>
     985      <p id="rfc.section.2.7.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
     986      </p>
     987      <p id="rfc.section.2.7.p.7"> <span class="comment" id="ISSUE-how-head">[<a href="#ISSUE-how-head" class="smpl">ISSUE-how-head</a>: discuss how to handle HEAD updates]</span>
    988988      </p>
    989989      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     
    10701070            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10711071            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1072             a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></li>
     1072            a stale response of any age. <span class="comment" id="TODO-staleness">[<a href="#TODO-staleness" class="smpl">TODO-staleness</a>: of any staleness? --mnot]</span></li>
    10731073      </ul>
    10741074      <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh
     
    15471547      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    15481548         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1549          computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    1550       </p>
    1551       <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     1549         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="TODO-nonmod">[<a href="#TODO-nonmod" class="smpl">TODO-nonmod</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     1550      </p>
     1551      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="TODO-nonmod2">[<a href="#TODO-nonmod2" class="smpl">TODO-nonmod2</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    15521552      </p>
    15531553      <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send
  • draft-ietf-httpbis/latest/p6-cache.xml

    r766 r767  
    506506  single Age header field (<xref target="header.age" />) in the response with a value equal to the stored response's
    507507  current_age; see <xref target="age.calculations" />.
    508   <cref>DISCUSS: this currently includes successfully validated responses.</cref>
     508  <cref anchor="DISCUSS-includes-validated">this currently includes successfully validated responses.</cref>
    509509</t>
    510510<t>
     
    545545  assign an explicit expiration time in the past. This means that the response is always
    546546  stale, so that caches should validate it before using it for subsequent requests.
    547   <cref>This wording may cause confusion, because the response may still be served stale.</cref>
     547  <cref anchor="TODO-response-stale">This wording may cause confusion, because the response may still be served stale.</cref>
    548548</t>
    549549<t>
     
    573573</t>
    574574<t>
    575   <cref>ISSUE: there are not requirements directly applying to cache-request-directives and
     575  <cref anchor="ISSUE-no-req-for-directives">there are not requirements directly applying to cache-request-directives and
    576576  freshness.</cref>
    577577</t>
     
    619619</t>
    620620<t>
    621   <cref>REVIEW: took away HTTP/1.0 query string heuristic uncacheability.</cref>
     621  <cref anchor="REVIEW-query-string-heuristics">took away HTTP/1.0 query string heuristic uncacheability.</cref>
    622622</t>
    623623</section>
     
    763763  of the stored responses nominated in the conditional request is
    764764  suitable. Instead, the full response is used both to satisfy the
    765   request and replace the stored response. <cref>Should there be a requirement here?</cref>
     765  request and replace the stored response. <cref anchor="TODO-req-missing">Should there be a requirement here?</cref>
    766766</t>
    767767<t>
     
    794794</t>
    795795<t>
    796   <cref>TODO: "host part" needs to be specified better.</cref>
     796  <cref anchor="TODO-def-host-part">"host part" needs to be specified better.</cref>
    797797</t>
    798798<t>
     
    811811</t>
    812812<t>
    813   <cref>TODO: specify that only successful (2xx, 3xx?) responses invalidate.</cref>
     813  <cref anchor="TODO-spec-success-invalidate">specify that only successful (2xx, 3xx?) responses invalidate.</cref>
    814814</t>
    815815</section>
     
    827827  selecting request-headers in the first request can be transformed to the selecting
    828828  request-headers in the second request by adding or removing linear white space
    829   <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
     829  <cref anchor="TODO-missing-ref">[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    830830  combining multiple message-header fields with the same field name following the rules
    831831  about header fields in &header-fields;.
     
    857857<t>
    858858  If the new response contains an ETag, it identifies the stored 
    859   response to use. <cref>may need language about Content-Location 
    860   here</cref><cref>cover case where INM with multiple etags was sent</cref>
     859  response to use. <cref anchor="TODO-mention-CL">may need language about Content-Location 
     860  here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref>
    861861</t>
    862862<t>
     
    882882</t>
    883883<t>
    884   The updated response can [[<cref>requirement?</cref>]] be used to replace the 
     884  The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the 
    885885  stored response in cache. In the case of a 206 response, the combined 
    886886  entity-body &MAY; be stored.
    887887</t>
    888888<t>
    889   <cref>ISSUE: discuss how to handle HEAD updates</cref>
     889  <cref anchor="ISSUE-how-head">discuss how to handle HEAD updates</cref>
    890890</t>
    891891</section>
     
    10371037      then the client is willing to accept a response that has exceeded its expiration
    10381038      time by no more than the specified number of seconds. If no value is assigned to
    1039       max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t>
     1039      max-stale, then the client is willing to accept a stale response of any age. <cref anchor="TODO-staleness" source="mnot">of any staleness?</cref></t>
    10401040  </list>
    10411041</t>
     
    20322032  delimiting); it was important to straighten out exactly how message lengths are computed.
    20332033  (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)
    2034   <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
     2034  <cref anchor="TODO-nonmod" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
    20352035</t>
    20362036<t>
    20372037  Proxies should be able to add Content-Length when appropriate.
    2038   <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
     2038  <cref anchor="TODO-nonmod2" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
    20392039</t>
    20402040<t
  • draft-ietf-httpbis/latest/p7-auth.html

    r765 r767  
    394394      <meta name="dct.creator" content="Reschke, J. F.">
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-03-02">
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-03-03">
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    398398      <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.">
     
    425425            </tr>
    426426            <tr>
    427                <td class="left">Expires: September 3, 2010</td>
     427               <td class="left">Expires: September 4, 2010</td>
    428428               <td class="right">HP</td>
    429429            </tr>
     
    478478            <tr>
    479479               <td class="left"></td>
    480                <td class="right">March 2, 2010</td>
     480               <td class="right">March 3, 2010</td>
    481481            </tr>
    482482         </tbody>
     
    508508      <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
    509509      </p>
    510       <p>This Internet-Draft will expire in September 3, 2010.</p>
     510      <p>This Internet-Draft will expire in September 4, 2010.</p>
    511511      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    512512      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    797797      </p>
    798798      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    799       <p id="rfc.section.6.p.1"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD.]</span>
     799      <p id="rfc.section.6.p.1"> <span class="comment" id="acks">[<a href="#acks" class="smpl">acks</a>: TBD.]</span>
    800800      </p>
    801801      <h1 id="rfc.references"><a id="rfc.section.7" href="#rfc.section.7">7.</a> References
  • draft-ietf-httpbis/latest/p7-auth.xml

    r765 r767  
    595595<section title="Acknowledgments" anchor="ack">
    596596<t>
    597   <cref>TBD.</cref>
     597  <cref anchor="acks">TBD.</cref>
    598598</t>
    599599</section>
Note: See TracChangeset for help on using the changeset viewer.