Changeset 311 for draft-ietf-httpbis/orig/rfc2617.xml
- Timestamp:
- 22/08/08 11:56:21 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/orig/rfc2617.xml
r9 r311 1 <?xml version="1.0" encoding="utf-8"?> 1 <?xml version="1.0" encoding="UTF-8"?> 2 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 2 3 <?rfc toc="yes"?> 3 4 <?rfc symrefs="no"?> … … 20 21 <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> 21 22 ]> 22 <rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext' >23 <rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation='rfc2629grddl.xslt'> 23 24 <front> 24 25 <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> … … 147 148 <middle> 148 149 149 <section title="Access Authentication" anchor="access.authentication">150 <section title="Access Authentication"> 150 151 151 152 <section title="Reliance on the HTTP/1.1 Specification"> 152 153 <t> 153 154 This specification is a companion to the HTTP/1.1 specification <xref target="RFC2616"/>. 154 It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x: sec="2.1"/> of that document, and relies on155 It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x:rel="#notation.abnf"/> of that document, and relies on 155 156 both the non-terminals defined in that document and other aspects of 156 157 the HTTP/1.1 specification. … … 206 207 authentication schemes that issue a challenge. The realm value 207 208 (case-sensitive), in combination with the canonical root URL (the 208 absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x: sec="5.1.2"/>209 absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> 209 210 of <xref target="RFC2616"/>) of the server being accessed, defines the protection space. 210 211 These realms allow the protected resources on a server to be … … 273 274 authentication by origin servers. That is, they must forward the 274 275 WWW-Authenticate and Authorization headers untouched, and follow the 275 rules found in section <xref target="RFC2616" x:fmt="number" x: sec="14.8"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and276 rules found in section <xref target="RFC2616" x:fmt="number" x:rel="#header.authorization"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and 276 277 the Proxy-Authorization header fields are hop-by-hop headers (see 277 section <xref target="RFC2616" x:fmt="number" x: sec="13.5.1"/> of <xref target="RFC2616"/>).278 section <xref target="RFC2616" x:fmt="number" x:rel="#end-to-end.and.hop-by-hop.headers"/> of <xref target="RFC2616"/>). 278 279 </t> 279 280 </section> … … 895 896 <t> 896 897 The "Method" value is the HTTP request method as specified in section 897 <xref target="RFC2616" x:fmt="number" x: sec="5.1.1"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the898 request line as specified in section <xref target="RFC2616" x:fmt="number" x: sec="5.1.2"/> of <xref target="RFC2616"/>. This may be "*",899 an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x: sec="5.1.2"/> of898 <xref target="RFC2616" x:fmt="number" x:rel="#method"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the 899 request line as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of <xref target="RFC2616"/>. This may be "*", 900 an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of 900 901 <xref target="RFC2616"/>, but it &MUST; agree with the Request-URI. In particular, it &MUST; 901 902 be an "absoluteURL" if the Request-URI is an "absoluteURL". The … … 918 919 Implementers should be aware of how authenticated transactions 919 920 interact with shared caches. The HTTP/1.1 protocol specifies that 920 when a shared cache (see section <xref target="RFC2616" x:fmt="number" x: sec="13.7"/> of <xref target="RFC2616"/>) has received a request921 when a shared cache (see section <xref target="RFC2616" x:fmt="number" x:rel="#shared.and.non-shared.caches"/> of <xref target="RFC2616"/>) has received a request 921 922 containing an Authorization header and a response from relaying that 922 923 request, it &MUST-NOT; return that response as a reply to any other 923 request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x: sec="14.9"/> of <xref target="RFC2616"/>)924 request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x:rel="#header.cache-control"/> of <xref target="RFC2616"/>) 924 925 directives was present in the response. If the original response 925 926 included the "must-revalidate" Cache-Control directive, the cache &MAY; … … 1270 1271 period of time or number of uses, or any other restrictions. Doing 1271 1272 so strengthens the protection provided against, for example, replay 1272 attacks (see 4.5). However, it should be noted that the method1273 attacks (see <xref target="replay.attacks" format="counter"/>). However, it should be noted that the method 1273 1274 chosen for generating and checking the nonce also has performance and 1274 1275 resource implications. For example, a server may choose to allow … … 1313 1314 </section> 1314 1315 1315 <section title="Replay Attacks" >1316 <section title="Replay Attacks" anchor="replay.attacks"> 1316 1317 <t> 1317 1318 A replay attack against Digest authentication would usually be … … 1905 1906 </front> 1906 1907 <seriesInfo name="RFC" value="2616"/> 1908 1909 <x:source href="rfc2616.xml"/> 1907 1910 </reference> 1908 1911
Note: See TracChangeset
for help on using the changeset viewer.