Changeset 2079 for draft-ietf-httpbis


Ignore:
Timestamp:
02/01/13 09:41:55 (10 years ago)
Author:
fielding@…
Message:

update generated html

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p0-introduction.html

    r2049 r2079  
    393393  }
    394394  @bottom-center {
    395        content: "Expires June 14, 2013";
     395       content: "Expires June 2013";
    396396  }
    397397  @bottom-right {
    … …  
    426426      <meta name="dct.creator" content="Reschke, J. F.">
    427427      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
    428       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     428      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    429429      <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    430430      <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    … …  
    446446            </tr>
    447447            <tr>
    448                <td class="left">Expires: June 14, 2013</td>
     448               <td class="left">Expires: June 2013</td>
    449449               <td class="right">W3C</td>
    450450            </tr>
    … …  
    467467            <tr>
    468468               <td class="left"></td>
    469                <td class="right">December 11, 2012</td>
     469               <td class="right">December 2012</td>
    470470            </tr>
    471471         </tbody>
    … …  
    490490         in progress”.
    491491      </p>
    492       <p>This Internet-Draft will expire on June 14, 2013.</p>
     492      <p>This Internet-Draft will expire in June 2013.</p>
    493493      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    494494      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2074 r2079  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 4, 2013";
     451       content: "Expires June 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 31, 2012</td>
     522               <td class="right">December 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: July 4, 2013</td>
     525               <td class="left">Expires: June 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on July 4, 2013.</p>
     553      <p>This Internet-Draft will expire in June 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2077 r2079  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 4, 2013";
     451       content: "Expires June 2013";
    452452  }
    453453  @bottom-right {
    … …  
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">December 31, 2012</td>
     525               <td class="right">December 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: July 4, 2013</td>
     528               <td class="left">Expires: June 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on July 4, 2013.</p>
     556      <p>This Internet-Draft will expire in June 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    766766         </li>
    767767         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    768                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
    769                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
    770                <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
    771                <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    772                <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
    773                <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.6">Misuse of CONNECT</a></li>
    774                <li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
     768               <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
     769               <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
     770               <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></li>
     771               <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.product">Product Information</a></li>
     772               <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#fragment.leakage">Fragment after Redirects</a></li>
     773               <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#fingerprinting">Browser Fingerprinting</a></li>
    775774            </ul>
    776775         </li>
    … …  
    14071406      <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    14081407      </p>
    1409       <p id="rfc.section.4.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.4</a> for security considerations when used for forms.
    1410       </p>
    14111408      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    14121409      <div id="rfc.iref.h.1"></div>
    … …  
    15301527      <div id="rfc.iref.c.9"></div>
    15311528      <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
    1532       <p id="rfc.section.4.3.6.p.1">The CONNECT method is only applicable as a request to a proxy. A CONNECT requests that the recipient establish a tunnel to
    1533          the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind
    1534          forwarding of packets, in both directions, until the connection is closed.
    1535       </p>
    1536       <p id="rfc.section.4.3.6.p.2">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1529      <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target
     1530         and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the connection
     1531         is closed.
     1532      </p>
     1533      <p id="rfc.section.4.3.6.p.2">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
     1534      </p>
     1535      <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    15371536         For example,
    15381537      </p>
    … …  
    15401539Host: server.example.com:80
    15411540
    1542 </pre><p id="rfc.section.4.3.6.p.4">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
    1543          proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the sender (and any inbound proxies) will switch to tunnel mode immediately after
    1544          the blank line that concludes the successful response's header block; data received after that blank line is from the server
    1545          identified by the request-target.
    1546       </p>
    1547       <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
    1548       </p>
    1549       <p id="rfc.section.4.3.6.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
    1550          governed by HTTP.
    1551       </p>
    1552       <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
     1541</pre><p id="rfc.section.4.3.6.p.5">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
     1542         proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that
     1543         concludes the successful response's header block; data received after that blank line is from the server identified by the
     1544         request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the
     1545         connection remains governed by HTTP.
     1546      </p>
     1547      <p id="rfc.section.4.3.6.p.6">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
     1548      </p>
     1549      <p id="rfc.section.4.3.6.p.7">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known
     1550         or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25"
     1551         would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying
     1552         spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.
     1553      </p>
     1554      <p id="rfc.section.4.3.6.p.8">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
    15531555      <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    15541556Host: server.example.com:80
    15551557Proxy-Authorization: basic aGVsbG86d29ybGQ=
    15561558
    1557 </pre><p id="rfc.section.4.3.6.p.9">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
     1559</pre><p id="rfc.section.4.3.6.p.10">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
    15581560         some existing implementations to reject the request.
    15591561      </p>
    1560       <p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
     1562      <p id="rfc.section.4.3.6.p.11">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
    15611563         will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left
    15621564         undelivered, that data will be discarded.
    1563       </p>
    1564       <p id="rfc.section.4.3.6.p.11">An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
    15651565      </p>
    15661566      <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
    … …  
    19211921      <p id="rfc.section.5.3.3.p.6">A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose
    19221922         user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets
    1923          makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (a.k.a., fingerprinting).
     1923         makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (<a href="#fingerprinting" title="Browser Fingerprinting">Section&nbsp;9.6</a>).
    19241924      </p>
    19251925      <p id="rfc.section.5.3.3.p.7">If an Accept-Charset header field is present in a request and none of the available representations for the response has a
    … …  
    19871987      </div>
    19881988      <p id="rfc.section.5.3.5.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
    1989          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;9.7</a>.
     1989         preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section&nbsp;9.6</a>).
    19901990      </p>
    19911991      <p id="rfc.section.5.3.5.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    … …  
    20862086         is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource
    20872087         that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user
    2088          agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">SHOULD NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.4</a> for additional security considerations.
     2088         agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">SHOULD NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section&nbsp;9.3</a> for additional security considerations.
    20892089      </p>
    20902090      <p id="rfc.section.5.5.2.p.8">Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the
    … …  
    37673767         semantics and its use for transferring information over the Internet.
    37683768      </p>
    3769       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
    3770       <p id="rfc.section.9.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to
    3771          interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information
    3772          about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional
    3773          leakage of this information.
    3774       </p>
    3775       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    3776       <p id="rfc.section.9.2.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents sent in response to HTTP requests to be only those that were intended by the server administrators.
    3777          If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    3778          Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    3779          such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended
    3780          to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
    3781          control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
    3782       </p>
    3783       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
    3784       <p id="rfc.section.9.3.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
    3785          a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    3786          Therefore, applications ought to supply as much control over this information as possible to the provider of that information.
    3787          Four header fields are worth special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>.
    3788       </p>
    3789       <p id="rfc.section.9.3.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    3790          against software that is known to contain security holes. Implementers <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option.
    3791       </p>
    3792       <p id="rfc.section.9.3.p.3">Proxies that serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that might identify hosts behind the firewall. In particular,
    3793          they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall.
    3794       </p>
    3795       <p id="rfc.section.9.3.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
    3796          be abused if user details are not separated from the information contained in the Referer. Even when the personal information
    3797          has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate.
    3798       </p>
    3799       <p id="rfc.section.9.3.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    3800       </p>
    3801       <p id="rfc.section.9.3.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    3802          of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
    3803       </p>
    3804       <p id="rfc.section.9.3.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields can sometimes be used to determine if a specific client or server is more likely to be vulnerable to a known
    3805          security hole. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    3806          no better mechanism.
    3807       </p>
    3808       <p id="rfc.section.9.3.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the
    3809          user.
    3810       </p>
    3811       <p id="rfc.section.9.3.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
    3812          to collect data from the client.
    3813       </p>
    3814       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    3815       <p id="rfc.section.9.4.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added
     3769      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
     3770      <p id="rfc.section.9.1.p.1">Origin servers frequently make use of their local file system to manage the mapping from effective request URI to resource
     3771         representations. Implementors need to be aware that most file systems are not designed to protect against malicious file or
     3772         path names, and thus depend on the origin server to avoid mapping to file names, folders, or directories that have special
     3773         significance to the system.
     3774      </p>
     3775      <p id="rfc.section.9.1.p.2">For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level
     3776         above the current one, and use specially named paths or file names to send data to system devices. Similar naming conventions
     3777         might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness
     3778         over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization
     3779         of case-insensitive names.
     3780      </p>
     3781      <p id="rfc.section.9.1.p.3">Attacks based on such special names tend to focus on either denial of service (e.g., telling the server to read from a COM
     3782         port) or disclosure of configuration and source files that are not meant to be served.
     3783      </p>
     3784      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
     3785      <p id="rfc.section.9.2.p.1">Clients are often privy to large amounts of personal information, including both information provided by the user to interact
     3786         with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the
     3787         user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional leakage
     3788         of personal information.
     3789      </p>
     3790      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="sensitive.information.in.uris" href="#sensitive.information.in.uris">Sensitive Information in URIs</a></h2>
     3791      <p id="rfc.section.9.3.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added
    38163792         to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include
    38173793         information within a URI that is sensitive, personally identifiable, or a risk to disclose.
    38183794      </p>
    3819       <p id="rfc.section.9.4.p.2">Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal
    3820          information about the user's immediate browsing history and any personal information that might be found in the referring
    3821          resource's URI. Further discussion of Referer considerations can be found in <a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;5.5.2</a>.
    3822       </p>
    3823       <p id="rfc.section.9.4.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
    3824          servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
    3825          Such services ought to use POST-based form submission instead.
    3826       </p>
    3827       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    3828       <p id="rfc.section.9.5.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 <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to
    3829          invalidate resources over which they have no authority.
    3830       </p>
    3831       <p id="rfc.section.9.5.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted
    3832          in the final request, it might be visible to the user agent through other means, such as scripting.
    3833       </p>
    3834       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;Misuse of CONNECT
    3835       </h2>
    3836       <p id="rfc.section.9.6.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
    3837          An HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    3838       </p>
    3839       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    3840       <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers that are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
    3841          of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents that offer
    3842          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    3843          to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    3844       </p>
    3845       <p id="rfc.section.9.7.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
    3846          by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
    3847          looking for any <a href="#header.vary" class="smpl">Vary</a> header fields generated by the server, that such sending could improve the quality of service.
    3848       </p>
    3849       <p id="rfc.section.9.7.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
    3850          used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
    3851          to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
    3852          of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will
    3853          also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
    3854          be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies
    3855          could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header
    3856          field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
     3795      <p id="rfc.section.9.3.p.2">Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in
     3796         the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might
     3797         be visible to third parties. Such services ought to use POST-based form submission instead.
     3798      </p>
     3799      <p id="rfc.section.9.3.p.3">Since the <a href="#header.referer" class="smpl">Referer</a> header field tells a target site about the context that resulted in a request, it has the potential to reveal information
     3800         about the user's immediate browsing history and any personal information that might be found in the referring resource's URI.
     3801         Limitations on Referer are described in <a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;5.5.2</a> to address some of its security considerations.
     3802      </p>
     3803      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="sensitive.information.in.product" href="#sensitive.information.in.product">Product Information</a></h2>
     3804      <p id="rfc.section.9.4.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier
     3805         for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the
     3806         apparent software versions being used.
     3807      </p>
     3808      <p id="rfc.section.9.4.p.2">Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header
     3809         information that might identify hosts behind the firewall. The <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field allows intermediaries to replace sensitive machine names with pseudonyms.
     3810      </p>
     3811      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="fragment.leakage" href="#fragment.leakage">Fragment after Redirects</a></h2>
     3812      <p id="rfc.section.9.5.p.1">Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they
     3813         will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a
     3814         redirect occurs and the original request's fragment identifier is inherited by the new reference in <a href="#header.location" class="smpl">Location</a> (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;7.1.2</a>), this might have the effect of leaking one site's fragment to another site. If the first site uses personal information
     3815         in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block
     3816         that inheritance.
     3817      </p>
     3818      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="fingerprinting" href="#fingerprinting">Browser Fingerprinting</a></h2>
     3819      <p id="rfc.section.9.6.p.1">Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics.
     3820         These characteristics might include information related to its TCP behavior, feature capabilities, and scripting environment,
     3821         though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting
     3822         is considered a privacy concern because it enables tracking of a user agent's behavior over time without the corresponding
     3823         controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e.,
     3824         Web browsers) have taken steps to reduce their fingerprints.
     3825      </p>
     3826      <p id="rfc.section.9.6.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable
     3827         fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by
     3828         the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so we can assume that fingerprinting
     3829         concerns only apply to situations where cookies are disabled or restricted by browser configuration.
     3830      </p>
     3831      <p id="rfc.section.9.6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics,
     3832         particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique
     3833         information that is least expected by users is <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), including the <a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-charset" class="smpl">Accept-Charset</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, and <a href="#header.accept-language" class="smpl">Accept-Language</a> header fields.
     3834      </p>
     3835      <p id="rfc.section.9.6.p.4">In addition to the fingerprinting concern, detailed use of the <a href="#header.accept-language" class="smpl">Accept-Language</a> header field can reveal information the user might consider to be of a private nature, because the understanding of particular
     3836         languages is often strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy
     3837         would be for a user agent to omit the sending of Accept-Language except for sites that have been whitelisted, perhaps via
     3838         interaction after detecting a <a href="#header.vary" class="smpl">Vary</a> header field that would indicate language negotiation might be useful.
     3839      </p>
     3840      <p id="rfc.section.9.6.p.5">In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation
     3841         header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users
     3842         about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter
     3843         the proactive negotiation header fields in relayed requests.
    38573844      </p>
    38583845      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    3859       <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     3846      <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    38603847      </p>
    38613848      <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References
    … …  
    41554142      <p id="rfc.section.C.p.11">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section&nbsp;4.3.6</a>)
    41564143      </p>
    4157       <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section&nbsp;4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section&nbsp;4.3.8</a>)
     4144      <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section&nbsp;4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>)
    41584145      </p>
    41594146      <p id="rfc.section.C.p.13">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well).
    … …  
    41794166      </p>
    41804167      <p id="rfc.section.C.p.22">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications
    4181          as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;7.1.2</a>)
     4168         as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section&nbsp;7.1.2</a>)
    41824169      </p>
    41834170      <p id="rfc.section.C.p.23">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section&nbsp;6.4.4</a>)
    … …  
    41994186         trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;7.4.1</a>)
    42004187      </p>
    4201       <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;7.4.2</a>)
     4188      <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;7.4.2</a>)
    42024189      </p>
    42034190      <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>)
    … …  
    42244211         (any visible US-ASCII character).
    42254212      </p>
    4226       <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    4227       </p>
    4228       <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4229   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4230   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4231   <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4232   <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4233   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4234   <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    4235   <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4236   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4237   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4238   <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4213      <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     4214      </p>
     4215      <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4216  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4217  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4218  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4219  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4220  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4221  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
     4222  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4223  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4224  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4225  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    42394226</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    42404227      <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    … …  
    45754562            </li>
    45764563            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    4577                   <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li>
     4564                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">C</a></li>
    45784565               </ul>
    45794566            </li>
    … …  
    45884575            </li>
    45894576            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4590                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.44">C</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a><ul>
     4577                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">C</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul>
    45914578                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    45924579                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    45934580                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.6.6</a></li>
    4594                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>
    4595                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.52">D</a></li>
    4596                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>
    4597                         <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>
     4581                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a></li>
     4582                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.53">D</a></li>
     4583                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a></li>
     4584                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a></li>
    45984585                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li>
    45994586                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.1.2</a></li>
    … …  
    46094596                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
    46104597                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li>
    4611                         <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li>
     4598                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.45">C</a></li>
    46124599                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.3.4</a></li>
    46134600                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li>
    46144601                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.27">6.5.15</a></li>
    46154602                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a></li>
    4616                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">10</a></li>
     4603                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">10</a></li>
    46174604                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">8.3.1</a></li>
    46184605                     </ul>
    … …  
    46674654            </li>
    46684655            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    4669                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.4</a>, <a href="#rfc.xref.header.referer.4">C</a></li>
     4656                  <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.3</a>, <a href="#rfc.xref.header.referer.4">C</a></li>
    46704657                  <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">3</a></li>
    46714658                  <li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li>
    … …  
    47564743                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>4.2.1</b></a></li>
    47574744                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>7.2</b></a></li>
    4758                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.3</a>, <a href="#rfc.xref.header.server.4">C</a></li>
     4745                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.4</a>, <a href="#rfc.xref.header.server.4">C</a></li>
    47594746                  <li>Status Codes Classes&nbsp;&nbsp;
    47604747                     <ul>
    … …  
    47704757            </li>
    47714758            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    4772                   <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.xref.TRACE.4">9.3</a>, <a href="#rfc.extref.t.50">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>
     4759                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">C</a>, <a href="#rfc.xref.TRACE.4">C</a></li>
    47734760               </ul>
    47744761            </li>
    47754762            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    4776                   <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.3</a></li>
     4763                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.4</a></li>
    47774764               </ul>
    47784765            </li>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r2074 r2079  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 4, 2013";
     451       content: "Expires June 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    … …  
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 4, 2013</td>
    520                <td class="right">December 31, 2012</td>
     519               <td class="left">Expires: June 2013</td>
     520               <td class="right">December 2012</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 4, 2013.</p>
     547      <p>This Internet-Draft will expire in June 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p5-range.html

    r2073 r2079  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 4, 2013";
     451       content: "Expires June 2013";
    452452  }
    453453  @bottom-right {
    … …  
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     495      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
    … …  
    519519            </tr>
    520520            <tr>
    521                <td class="left">Expires: July 4, 2013</td>
     521               <td class="left">Expires: June 2013</td>
    522522               <td class="right">J. Reschke, Editor</td>
    523523            </tr>
    … …  
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">December 31, 2012</td>
     530               <td class="right">December 2012</td>
    531531            </tr>
    532532         </tbody>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 4, 2013.</p>
     555      <p>This Internet-Draft will expire in June 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p6-cache.html

    r2074 r2079  
    452452  }
    453453  @bottom-center {
    454        content: "Expires July 4, 2013";
     454       content: "Expires June 2013";
    455455  }
    456456  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 4, 2013</td>
     526               <td class="left">Expires: June 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
    … …  
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">December 31, 2012</td>
     535               <td class="right">December 2012</td>
    536536            </tr>
    537537         </tbody>
    … …  
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on July 4, 2013.</p>
     561      <p>This Internet-Draft will expire in June 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r2074 r2079  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 4, 2013";
     451       content: "Expires June 2013";
    452452  }
    453453  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-12">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
    … …  
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">December 31, 2012</td>
     519               <td class="right">December 2012</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: July 4, 2013</td>
     522               <td class="left">Expires: June 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
    … …  
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on July 4, 2013.</p>
     548      <p>This Internet-Draft will expire in June 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.