Changeset 1514 for draft-ietf-httpbis/latest
- Timestamp:
- 26/01/12 14:54:04 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1511 r1514 358 358 } 359 359 @bottom-center { 360 content: "Expires July 2 8, 2012";360 content: "Expires July 29, 2012"; 361 361 } 362 362 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 5">410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-26"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: July 2 8, 2012</td>442 <td class="left">Expires: July 29, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">January 2 5, 2012</td>495 <td class="right">January 26, 2012</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on July 2 8, 2012.</p>528 <p>This Internet-Draft will expire on July 29, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1053 1053 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1054 1054 </p> 1055 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary1055 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary 1056 1056 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 1057 1057 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message … … 1964 1964 request includes a request body, and the server responds with a final status code before reading the entire request body from 1965 1965 the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, 1966 the client might not reliably receive the response message. However, this requirement is not be construed as preventing a1967 server from defending itself against denial-of-service attacks, or from badly broken client implementations.1966 the client might not reliably receive the response message. However, this requirement ought not be construed as preventing 1967 a server from defending itself against denial-of-service attacks, or from badly broken client implementations. 1968 1968 </li> 1969 1969 </ul> … … 2138 2138 <div id="rfc.iref.h.10"></div> 2139 2139 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.te" href="#header.te">TE</a></h2> 2140 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not2141 it is willing to accept trailer fields in a chunked transfer-coding.2140 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether 2141 or not it is willing to accept trailer fields in a chunked transfer-coding. 2142 2142 </p> 2143 2143 <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional … … 2180 2180 </li> 2181 2181 </ol> 2182 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding2183 is always acceptable.2182 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 2183 no transfer-coding is always acceptable. 2184 2184 </p> 2185 2185 <div id="rfc.iref.t.6"></div> … … 2225 2225 </pre><p id="rfc.section.8.7.p.3">For example,</p> 2226 2226 <div id="rfc.figure.u.60"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2228 2228 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2229 2229 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2648 2648 configuration options they provide to proxy operators (especially the default configuration). 2649 2649 </p> 2650 <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no trustworthierthan the people who run them; HTTP itself cannot solve2650 <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve 2651 2651 this problem. 2652 2652 </p> … … 2918 2918 designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand 2919 2919 any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood 2920 (or safely ignored) by HTTP/1.0 clients. Likewise, w ould expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.2920 (or safely ignored) by HTTP/1.0 clients. Likewise, we would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response. 2921 2921 </p> 2922 2922 <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts -
draft-ietf-httpbis/latest/p1-messaging.xml
r1511 r1514 896 896 <t> 897 897 Intermediaries that process HTTP messages (i.e., all intermediaries 898 other than those acting as a tunnel) &MUST; send their own HTTP-Version898 other than those acting as tunnels) &MUST; send their own HTTP-Version 899 899 in forwarded messages. In other words, they &MUST-NOT; blindly 900 900 forward the first line of an HTTP message without ensuring that the … … 2794 2794 or until the client closes the connection. Otherwise, the client 2795 2795 might not reliably receive the response message. However, this 2796 requirement isnot be construed as preventing a server from2796 requirement ought not be construed as preventing a server from 2797 2797 defending itself against denial-of-service attacks, or from 2798 2798 badly broken client implementations. … … 3089 3089 <t> 3090 3090 The "TE" header field indicates what extension transfer-codings 3091 it is willing to accept in the response, and whether or not it is3091 the client is willing to accept in the response, and whether or not it is 3092 3092 willing to accept trailer fields in a chunked transfer-coding. 3093 3093 </t> … … 3157 3157 <t> 3158 3158 If the TE field-value is empty or if no TE field is present, the only 3159 transfer-coding is "chunked". A message with no transfer-coding is3159 acceptable transfer-coding is "chunked". A message with no transfer-coding is 3160 3160 always acceptable. 3161 3161 </t> … … 3249 3249 <t> 3250 3250 The Upgrade header field is intended to provide a simple mechanism 3251 for transition from HTTP/1.1 to some other, incompatible protocol. It3251 for transitioning from HTTP/1.1 to some other, incompatible protocol. It 3252 3252 does so by allowing the client to advertise its desire to use another 3253 3253 protocol, such as a later version of HTTP with a higher major version … … 3838 3838 </t> 3839 3839 <t> 3840 Users of a proxy need to be aware that proxies are no trustworthierthan3840 Users of a proxy need to be aware that proxies are no more trustworthy than 3841 3841 the people who run them; HTTP itself cannot solve this problem. 3842 3842 </t> … … 4859 4859 any valid request in the format of HTTP/1.0 and respond appropriately 4860 4860 with an HTTP/1.1 message that only uses features understood (or 4861 safely ignored) by HTTP/1.0 clients. Likewise, w ould expect4861 safely ignored) by HTTP/1.0 clients. Likewise, we would expect 4862 4862 an HTTP/1.1 client to understand any valid HTTP/1.0 response. 4863 4863 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1512 r1514 358 358 } 359 359 @bottom-center { 360 content: "Expires July 2 8, 2012";360 content: "Expires July 29, 2012"; 361 361 } 362 362 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 5">412 <meta name="dct.issued" scheme="ISO8601" content="2012-01-26"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 414 414 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 441 441 </tr> 442 442 <tr> 443 <td class="left">Expires: July 2 8, 2012</td>443 <td class="left">Expires: July 29, 2012</td> 444 444 <td class="right">HP</td> 445 445 </tr> … … 494 494 <tr> 495 495 <td class="left"></td> 496 <td class="right">January 2 5, 2012</td>496 <td class="right">January 26, 2012</td> 497 497 </tr> 498 498 </tbody> … … 524 524 in progress”. 525 525 </p> 526 <p>This Internet-Draft will expire on July 2 8, 2012.</p>526 <p>This Internet-Draft will expire on July 29, 2012.</p> 527 527 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 528 528 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2228 2228 </p> 2229 2229 <p id="rfc.section.9.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it 2230 when it doesn't convey any useful information (as i t is usually the case for requests that do not contain a payload).2230 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2231 2231 </p> 2232 2232 <p id="rfc.section.9.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means … … 2321 2321 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2322 2322 <p id="rfc.section.9.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2323 to trace a request which appears to be failing or looping inmid-chain.2323 to trace a request which appears to be failing or looping mid-chain. 2324 2324 </p> 2325 2325 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> … … 2352 2352 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 2353 2353 <p id="rfc.section.9.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2354 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing2354 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing 2355 2355 the redirected request. 2356 2356 </p> … … 2831 2831 of From and Referer information. 2832 2832 </p> 2833 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.9</a>) header fields can sometimes be used to determine that a specific client or server ha ve a particular security hole which2834 might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently2835 hasno better mechanism.2833 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 2834 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 2835 no better mechanism. 2836 2836 </p> 2837 2837 <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material, -
draft-ietf-httpbis/latest/p2-semantics.xml
r1512 r1514 2566 2566 Clients can use the Date header field as well; in order to keep request 2567 2567 messages small, they are advised not to include it when it doesn't convey 2568 any useful information (as i t is usually the case for requests that do not2568 any useful information (as is usually the case for requests that do not 2569 2569 contain a payload). 2570 2570 </t> … … 2757 2757 methods to limit the number of times that the request is forwarded by 2758 2758 proxies. This can be useful when the client is attempting to 2759 trace a request which appears to be failing or looping inmid-chain.2759 trace a request which appears to be failing or looping mid-chain. 2760 2760 </t> 2761 2761 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> … … 2829 2829 be unavailable to the requesting client. This field &MAY; also be used 2830 2830 with any 3xx (Redirection) response to indicate the minimum time the 2831 user-agent is asked wait before issuing the redirected request.2831 user-agent is asked to wait before issuing the redirected request. 2832 2832 </t> 2833 2833 <t> … … 3350 3350 The User-Agent (<xref target="header.user-agent"/>) or Server (<xref 3351 3351 target="header.server"/>) header fields can sometimes be used to determine 3352 that a specific client or server ha vea particular security hole which might3352 that a specific client or server has a particular security hole which might 3353 3353 be exploited. Unfortunately, this same information is often used for other 3354 3354 valuable purposes for which HTTP currently has no better mechanism. -
draft-ietf-httpbis/latest/p3-payload.html
r1506 r1514 358 358 } 359 359 @bottom-center { 360 content: "Expires July 17, 2012";360 content: "Expires July 29, 2012"; 361 361 } 362 362 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2012-01- 14">411 <meta name="dct.issued" scheme="ISO8601" content="2012-01-26"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <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 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: July 17, 2012</td>437 <td class="left">Expires: July 29, 2012</td> 438 438 <td class="right">J. Mogul</td> 439 439 </tr> … … 492 492 <tr> 493 493 <td class="left"></td> 494 <td class="right">January 14, 2012</td>494 <td class="right">January 26, 2012</td> 495 495 </tr> 496 496 </tbody> … … 520 520 in progress”. 521 521 </p> 522 <p>This Internet-Draft will expire on July 17, 2012.</p>522 <p>This Internet-Draft will expire on July 29, 2012.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 753 753 <li>Pointer to specification text</li> 754 754 </ul> 755 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as i t is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).755 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 756 756 </p> 757 757 <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 995 995 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 996 996 </ol> 997 <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always hono ur997 <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor 998 998 them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response 999 999 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. … … 1475 1475 </p> 1476 1476 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <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> 1477 <p id="rfc.section.8.1.p.1">Accept header s fields can reveal information about the user to all servers which are accessed. The Accept-Language header1478 field in particular can reveal information the user would consider to be of a private nature, because the understanding of1479 particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer1480 t he option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged1481 to let theconfiguration process include a message which makes the user aware of the loss of privacy involved.1477 <p id="rfc.section.8.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field 1478 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 1479 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option 1480 to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the 1481 configuration process include a message which makes the user aware of the loss of privacy involved. 1482 1482 </p> 1483 1483 <p id="rfc.section.8.1.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 -
draft-ietf-httpbis/latest/p3-payload.xml
r1506 r1514 456 456 <t> 457 457 Names of content codings &MUST-NOT; overlap with names of transfer codings 458 (&transfer-codings;), unless the encoding transformation is identical (as it458 (&transfer-codings;), unless the encoding transformation is identical (as 459 459 is the case for the compression codings defined in 460 460 &compression-codings;). … … 858 858 <t> 859 859 Server-driven negotiation allows the user agent to specify its preferences, 860 but it cannot expect responses to always hono ur them. For example, the origin860 but it cannot expect responses to always honor them. For example, the origin 861 861 server might not implement server-driven negotiation, or it might decide that 862 862 sending a response that doesn't conform to them is better than sending a 406 … … 1598 1598 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields"> 1599 1599 <t> 1600 Accept header sfields can reveal information about the user to all1600 Accept header fields can reveal information about the user to all 1601 1601 servers which are accessed. The Accept-Language header field in particular 1602 1602 can reveal information the user would consider to be of a private -
draft-ietf-httpbis/latest/p4-conditional.html
r1504 r1514 358 358 } 359 359 @bottom-center { 360 content: "Expires July 7, 2012";360 content: "Expires July 29, 2012"; 361 361 } 362 362 @bottom-right { … … 405 405 <meta name="dct.creator" content="Reschke, J. F."> 406 406 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 407 <meta name="dct.issued" scheme="ISO8601" content="2012-01- 04">407 <meta name="dct.issued" scheme="ISO8601" content="2012-01-26"> 408 408 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 409 409 <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 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 431 431 </tr> 432 432 <tr> 433 <td class="left">Expires: July 7, 2012</td>433 <td class="left">Expires: July 29, 2012</td> 434 434 <td class="right">J. Mogul</td> 435 435 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">January 4, 2012</td>490 <td class="right">January 26, 2012</td> 491 491 </tr> 492 492 </tbody> … … 518 518 in progress”. 519 519 </p> 520 <p>This Internet-Draft will expire on July 7, 2012.</p>520 <p>This Internet-Draft will expire on July 29, 2012.</p> 521 521 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 522 522 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 979 979 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 980 980 If-Match: * 981 </pre><p id="rfc.section.3.1.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header field s981 </pre><p id="rfc.section.3.1.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header field 982 982 is undefined by this specification. 983 983 </p> … … 1013 1013 If-None-Match: * 1014 1014 </pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header 1015 field sis undefined by this specification.1015 field is undefined by this specification. 1016 1016 </p> 1017 1017 <div id="rfc.iref.i.3"></div> … … 1060 1060 </ul> 1061 1061 <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header 1062 field sis undefined by this specification.1062 field is undefined by this specification. 1063 1063 </p> 1064 1064 <div id="rfc.iref.i.4"></div> … … 1078 1078 </p> 1079 1079 <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since 1080 header field sis undefined by this specification.1080 header field is undefined by this specification. 1081 1081 </p> 1082 1082 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1500 r1514 866 866 <t> 867 867 The result of a request having both an If-Match header field and 868 either an If-None-Match or an If-Modified-Since header field sis868 either an If-None-Match or an If-Modified-Since header field is 869 869 undefined by this specification. 870 870 </t> … … 936 936 <t> 937 937 The result of a request having both an If-None-Match header field and 938 either an If-Match or an If-Unmodified-Since header field sis938 either an If-Match or an If-Unmodified-Since header field is 939 939 undefined by this specification. 940 940 </t> … … 1019 1019 <t> 1020 1020 The result of a request having both an If-Modified-Since header field 1021 and either an If-Match or an If-Unmodified-Since header field sis1021 and either an If-Match or an If-Unmodified-Since header field is 1022 1022 undefined by this specification. 1023 1023 </t> … … 1058 1058 The result of a request having both an If-Unmodified-Since header 1059 1059 field and either an If-None-Match or an If-Modified-Since header 1060 field sis undefined by this specification.1060 field is undefined by this specification. 1061 1061 </t> 1062 1062 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r1513 r1514 812 812 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>) does not appear in request or response header fields, and 813 813 </li> 814 <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a> does not appear in the response, if the cache is shared, and814 <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) does not appear in the response, if the cache is shared, and 815 815 </li> 816 816 <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section 2.6</a>), and -
draft-ietf-httpbis/latest/p6-cache.xml
r1513 r1514 550 550 header fields, and</t> 551 551 <t>the "private" cache response directive (see <xref 552 target="cache-response-directive" /> does not appear in the response, if552 target="cache-response-directive" />) does not appear in the response, if 553 553 the cache is shared, and</t> 554 554 <t>the "Authorization" header field (see &header-authorization;) does not
Note: See TracChangeset
for help on using the changeset viewer.