1 | <?xml version="1.0" encoding="UTF-8"?> |
---|
2 | <!-- |
---|
3 | This XML document is the output of clean-for-DTD.xslt; a tool that strips |
---|
4 | extensions to RFC2629(bis) from documents for processing with xml2rfc. |
---|
5 | --> |
---|
6 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
7 | <?rfc toc="yes" ?> |
---|
8 | <?rfc symrefs="yes" ?> |
---|
9 | <?rfc sortrefs="yes" ?> |
---|
10 | <?rfc compact="yes"?> |
---|
11 | <?rfc subcompact="no" ?> |
---|
12 | <?rfc linkmailto="no" ?> |
---|
13 | <?rfc editing="no" ?> |
---|
14 | <?rfc comments="yes"?> |
---|
15 | <?rfc inline="yes"?> |
---|
16 | <?rfc rfcedstyle="yes"?> |
---|
17 | <!DOCTYPE rfc |
---|
18 | PUBLIC "" "rfc2629.dtd"> |
---|
19 | <rfc obsoletes="2616" updates="2617" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-18"> |
---|
20 | |
---|
21 | <front> |
---|
22 | |
---|
23 | <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title> |
---|
24 | |
---|
25 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
26 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
27 | <address> |
---|
28 | <postal> |
---|
29 | <street>345 Park Ave</street> |
---|
30 | <city>San Jose</city> |
---|
31 | <region>CA</region> |
---|
32 | <code>95110</code> |
---|
33 | <country>USA</country> |
---|
34 | </postal> |
---|
35 | <email>fielding@gbiv.com</email> |
---|
36 | <uri>http://roy.gbiv.com/</uri> |
---|
37 | </address> |
---|
38 | </author> |
---|
39 | |
---|
40 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
41 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
42 | <address> |
---|
43 | <postal> |
---|
44 | <street>21 Oak Knoll Road</street> |
---|
45 | <city>Carlisle</city> |
---|
46 | <region>MA</region> |
---|
47 | <code>01741</code> |
---|
48 | <country>USA</country> |
---|
49 | </postal> |
---|
50 | <email>jg@freedesktop.org</email> |
---|
51 | <uri>http://gettys.wordpress.com/</uri> |
---|
52 | </address> |
---|
53 | </author> |
---|
54 | |
---|
55 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
56 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
57 | <address> |
---|
58 | <postal> |
---|
59 | <street>HP Labs, Large Scale Systems Group</street> |
---|
60 | <street>1501 Page Mill Road, MS 1177</street> |
---|
61 | <city>Palo Alto</city> |
---|
62 | <region>CA</region> |
---|
63 | <code>94304</code> |
---|
64 | <country>USA</country> |
---|
65 | </postal> |
---|
66 | <email>JeffMogul@acm.org</email> |
---|
67 | </address> |
---|
68 | </author> |
---|
69 | |
---|
70 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
71 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
72 | <address> |
---|
73 | <postal> |
---|
74 | <street>1 Microsoft Way</street> |
---|
75 | <city>Redmond</city> |
---|
76 | <region>WA</region> |
---|
77 | <code>98052</code> |
---|
78 | <country>USA</country> |
---|
79 | </postal> |
---|
80 | <email>henrikn@microsoft.com</email> |
---|
81 | </address> |
---|
82 | </author> |
---|
83 | |
---|
84 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
85 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
86 | <address> |
---|
87 | <postal> |
---|
88 | <street>345 Park Ave</street> |
---|
89 | <city>San Jose</city> |
---|
90 | <region>CA</region> |
---|
91 | <code>95110</code> |
---|
92 | <country>USA</country> |
---|
93 | </postal> |
---|
94 | <email>LMM@acm.org</email> |
---|
95 | <uri>http://larry.masinter.net/</uri> |
---|
96 | </address> |
---|
97 | </author> |
---|
98 | |
---|
99 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
100 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
101 | <address> |
---|
102 | <postal> |
---|
103 | <street>1 Microsoft Way</street> |
---|
104 | <city>Redmond</city> |
---|
105 | <region>WA</region> |
---|
106 | <code>98052</code> |
---|
107 | </postal> |
---|
108 | <email>paulle@microsoft.com</email> |
---|
109 | </address> |
---|
110 | </author> |
---|
111 | |
---|
112 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
113 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
114 | <address> |
---|
115 | <postal> |
---|
116 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
117 | <street>The Stata Center, Building 32</street> |
---|
118 | <street>32 Vassar Street</street> |
---|
119 | <city>Cambridge</city> |
---|
120 | <region>MA</region> |
---|
121 | <code>02139</code> |
---|
122 | <country>USA</country> |
---|
123 | </postal> |
---|
124 | <email>timbl@w3.org</email> |
---|
125 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
126 | </address> |
---|
127 | </author> |
---|
128 | |
---|
129 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
130 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
131 | <address> |
---|
132 | <postal> |
---|
133 | <street>W3C / ERCIM</street> |
---|
134 | <street>2004, rte des Lucioles</street> |
---|
135 | <city>Sophia-Antipolis</city> |
---|
136 | <region>AM</region> |
---|
137 | <code>06902</code> |
---|
138 | <country>France</country> |
---|
139 | </postal> |
---|
140 | <email>ylafon@w3.org</email> |
---|
141 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
142 | </address> |
---|
143 | </author> |
---|
144 | |
---|
145 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
146 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
147 | <address> |
---|
148 | <postal> |
---|
149 | <street>Hafenweg 16</street> |
---|
150 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
151 | <country>Germany</country> |
---|
152 | </postal> |
---|
153 | <phone>+49 251 2807760</phone> |
---|
154 | <facsimile>+49 251 2807761</facsimile> |
---|
155 | <email>julian.reschke@greenbytes.de</email> |
---|
156 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
157 | </address> |
---|
158 | </author> |
---|
159 | |
---|
160 | <date month="January" year="2012" day="4"/> |
---|
161 | <workgroup>HTTPbis Working Group</workgroup> |
---|
162 | |
---|
163 | <abstract> |
---|
164 | <t> |
---|
165 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for |
---|
166 | distributed, collaborative, hypermedia information systems. HTTP has been in |
---|
167 | use by the World Wide Web global information initiative since 1990. This |
---|
168 | document is Part 7 of the seven-part specification that defines the protocol |
---|
169 | referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
---|
170 | </t> |
---|
171 | <t> |
---|
172 | Part 7 defines the HTTP Authentication framework. |
---|
173 | </t> |
---|
174 | </abstract> |
---|
175 | |
---|
176 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
177 | <t> |
---|
178 | Discussion of this draft should take place on the HTTPBIS working group |
---|
179 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
180 | <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>. |
---|
181 | </t> |
---|
182 | <t> |
---|
183 | The current issues list is at |
---|
184 | <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related |
---|
185 | documents (including fancy diffs) can be found at |
---|
186 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
187 | </t> |
---|
188 | <t> |
---|
189 | The changes in this draft are summarized in <xref target="changes.since.17"/>. |
---|
190 | </t> |
---|
191 | </note> |
---|
192 | </front> |
---|
193 | <middle> |
---|
194 | <section title="Introduction" anchor="introduction"> |
---|
195 | <t> |
---|
196 | This document defines HTTP/1.1 access control and authentication. It |
---|
197 | includes the relevant parts of RFC 2616 |
---|
198 | with only minor changes, plus the general framework for HTTP authentication, |
---|
199 | as previously defined in "HTTP Authentication: Basic and Digest Access |
---|
200 | Authentication" (<xref target="RFC2617"/>). |
---|
201 | </t> |
---|
202 | <t> |
---|
203 | HTTP provides several OPTIONAL challenge-response authentication |
---|
204 | mechanisms which can be used by a server to challenge a client request and |
---|
205 | by a client to provide authentication information. The "basic" and "digest" |
---|
206 | authentication schemes continue to be specified in |
---|
207 | RFC 2617. |
---|
208 | </t> |
---|
209 | |
---|
210 | <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> |
---|
211 | <t> |
---|
212 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
213 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
214 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
215 | </t> |
---|
216 | <t> |
---|
217 | This document defines conformance criteria for several roles in HTTP |
---|
218 | communication, including Senders, Recipients, Clients, Servers, User-Agents, |
---|
219 | Origin Servers, Intermediaries, Proxies and Gateways. See Section 2 of <xref target="Part1"/> |
---|
220 | for definitions of these terms. |
---|
221 | </t> |
---|
222 | <t> |
---|
223 | An implementation is considered conformant if it complies with all of the |
---|
224 | requirements associated with its role(s). Note that SHOULD-level requirements |
---|
225 | are relevant here, unless one of the documented exceptions is applicable. |
---|
226 | </t> |
---|
227 | <t> |
---|
228 | This document also uses ABNF to define valid protocol elements |
---|
229 | (<xref target="notation"/>). In addition to the prose requirements placed |
---|
230 | upon them, Senders MUST NOT generate protocol elements that are invalid. |
---|
231 | </t> |
---|
232 | <t> |
---|
233 | Unless noted otherwise, Recipients MAY take steps to recover a usable |
---|
234 | protocol element from an invalid construct. However, HTTP does not define |
---|
235 | specific error handling mechanisms, except in cases where it has direct |
---|
236 | impact on security. This is because different uses of the protocol require |
---|
237 | different error handling strategies; for example, a Web browser may wish to |
---|
238 | transparently recover from a response where the Location header field |
---|
239 | doesn't parse according to the ABNF, whereby in a systems control protocol |
---|
240 | using HTTP, this type of error recovery could lead to dangerous consequences. |
---|
241 | </t> |
---|
242 | </section> |
---|
243 | |
---|
244 | <section title="Syntax Notation" anchor="notation"> |
---|
245 | |
---|
246 | |
---|
247 | |
---|
248 | |
---|
249 | |
---|
250 | |
---|
251 | |
---|
252 | <t> |
---|
253 | This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which |
---|
254 | extends the syntax defined in <xref target="RFC5234"/> with a list rule). |
---|
255 | <xref target="collected.abnf"/> shows the collected ABNF, with the list |
---|
256 | rule expanded. |
---|
257 | </t> |
---|
258 | <t> |
---|
259 | The following core rules are included by |
---|
260 | reference, as defined in <xref target="RFC5234"/>, Appendix B.1: |
---|
261 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
262 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
263 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
264 | OCTET (any 8-bit sequence of data), SP (space), and |
---|
265 | VCHAR (any visible US-ASCII character). |
---|
266 | </t> |
---|
267 | |
---|
268 | <section title="Core Rules" anchor="core.rules"> |
---|
269 | |
---|
270 | |
---|
271 | |
---|
272 | |
---|
273 | <t> |
---|
274 | The core rules below are defined in <xref target="Part1"/>: |
---|
275 | </t> |
---|
276 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
277 | BWS = <BWS, defined in [Part1], Section 1.2.2> |
---|
278 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
279 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
---|
280 | token = <token, defined in [Part1], Section 3.2.3> |
---|
281 | ]]></artwork></figure> |
---|
282 | </section> |
---|
283 | </section> |
---|
284 | </section> |
---|
285 | |
---|
286 | <section title="Access Authentication Framework" anchor="access.authentication.framework"> |
---|
287 | |
---|
288 | <section title="Challenge and Response" anchor="challenge.and.response"> |
---|
289 | |
---|
290 | |
---|
291 | |
---|
292 | |
---|
293 | |
---|
294 | <t> |
---|
295 | HTTP provides a simple challenge-response authentication mechanism |
---|
296 | that can be used by a server to challenge a client request and by a |
---|
297 | client to provide authentication information. It uses an extensible, |
---|
298 | case-insensitive token to identify the authentication scheme, followed |
---|
299 | by additional information necessary for achieving authentication via that |
---|
300 | scheme. The latter can either be a comma-separated list of parameters or a |
---|
301 | single sequence of characters capable of holding base64-encoded |
---|
302 | information. |
---|
303 | </t> |
---|
304 | <t> |
---|
305 | Parameters are name-value pairs where the name is matched case-insensitively, |
---|
306 | and each parameter name MUST only occur once per challenge. |
---|
307 | </t> |
---|
308 | <figure><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/><iref primary="true" item="Grammar" subitem="auth-scheme"/><iref primary="true" item="Grammar" subitem="auth-param"/><iref item="b64token" primary="true"/><iref primary="true" item="Grammar" subitem="b64token"/><artwork type="abnf2616"><![CDATA[ |
---|
309 | auth-scheme = token |
---|
310 | |
---|
311 | auth-param = token BWS "=" BWS ( token / quoted-string ) |
---|
312 | |
---|
313 | b64token = 1*( ALPHA / DIGIT / |
---|
314 | "-" / "." / "_" / "~" / "+" / "/" ) *"=" |
---|
315 | ]]></artwork></figure> |
---|
316 | <t> |
---|
317 | The "b64token" syntax allows the 66 unreserved URI characters (<xref target="RFC3986"/>), |
---|
318 | plus a few others, so that it can hold a base64, base64url (URL and filename |
---|
319 | safe alphabet), base32, or base16 (hex) encoding, with or without padding, but |
---|
320 | excluding whitespace (<xref target="RFC4648"/>). |
---|
321 | </t> |
---|
322 | <t> |
---|
323 | The 401 (Unauthorized) response message is used by an origin server |
---|
324 | to challenge the authorization of a user agent. This response MUST |
---|
325 | include a WWW-Authenticate header field containing at least one |
---|
326 | challenge applicable to the requested resource. |
---|
327 | </t> |
---|
328 | <t> |
---|
329 | The 407 (Proxy Authentication Required) response message is used by a proxy to |
---|
330 | challenge the authorization of a client and MUST include a Proxy-Authenticate |
---|
331 | header field containing at least one challenge |
---|
332 | applicable to the proxy for the requested resource. |
---|
333 | </t> |
---|
334 | <figure><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/><artwork type="abnf2616"><![CDATA[ |
---|
335 | challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |
---|
336 | ]]></artwork></figure> |
---|
337 | <t><list> |
---|
338 | <t> |
---|
339 | Note: User agents will need to take special care in parsing the |
---|
340 | WWW-Authenticate and Proxy-Authenticate header field values because they |
---|
341 | can contain more than one challenge, or if more than one of each is |
---|
342 | provided, since the contents of a challenge can itself contain a |
---|
343 | comma-separated list of authentication parameters. |
---|
344 | </t> |
---|
345 | </list></t> |
---|
346 | <t><list> |
---|
347 | <t> |
---|
348 | Note: Many browsers fail to parse challenges containing unknown |
---|
349 | schemes. A workaround for this problem is to list well-supported schemes |
---|
350 | (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 --> |
---|
351 | </t> |
---|
352 | </list></t> |
---|
353 | <t> |
---|
354 | A user agent that wishes to authenticate itself with an origin server |
---|
355 | — usually, but not necessarily, after receiving a 401 (Unauthorized) |
---|
356 | — MAY do so by including an Authorization header field with the |
---|
357 | request. |
---|
358 | </t> |
---|
359 | <t> |
---|
360 | A client that wishes to authenticate itself with a proxy — usually, |
---|
361 | but not necessarily, after receiving a 407 (Proxy Authentication Required) |
---|
362 | — MAY do so by including a Proxy-Authorization header field with the |
---|
363 | request. |
---|
364 | </t> |
---|
365 | <t> |
---|
366 | Both the Authorization field value and the Proxy-Authorization field value |
---|
367 | consist of credentials containing the authentication information of the |
---|
368 | client for the realm of the resource being requested. The user agent MUST |
---|
369 | choose to use one of the challenges with the strongest auth-scheme it |
---|
370 | understands and request credentials from the user based upon that challenge. |
---|
371 | </t> |
---|
372 | <figure><iref item="credentials" primary="true"/><iref primary="true" item="Grammar" subitem="credentials"/><artwork type="abnf2616"><![CDATA[ |
---|
373 | credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |
---|
374 | ]]></artwork></figure> |
---|
375 | <t> |
---|
376 | If the origin server does not wish to accept the credentials sent |
---|
377 | with a request, it SHOULD return a 401 (Unauthorized) response. The |
---|
378 | response MUST include a WWW-Authenticate header field containing at |
---|
379 | least one (possibly new) challenge applicable to the requested |
---|
380 | resource. |
---|
381 | </t> |
---|
382 | <t> |
---|
383 | If a proxy does not accept the credentials sent with a |
---|
384 | request, it SHOULD return a 407 (Proxy Authentication Required). The |
---|
385 | response MUST include a Proxy-Authenticate header field containing a |
---|
386 | (possibly new) challenge applicable to the proxy for the requested |
---|
387 | resource. |
---|
388 | </t> |
---|
389 | <t> |
---|
390 | The HTTP protocol does not restrict applications to this simple |
---|
391 | challenge-response mechanism for access authentication. Additional |
---|
392 | mechanisms MAY be used, such as encryption at the transport level or |
---|
393 | via message encapsulation, and with additional header fields |
---|
394 | specifying authentication information. However, such additional |
---|
395 | mechanisms are not defined by this specification. |
---|
396 | </t> |
---|
397 | <t> |
---|
398 | Proxies MUST forward the WWW-Authenticate and Authorization headers |
---|
399 | unmodified and follow the rules found in <xref target="header.authorization"/>. |
---|
400 | </t> |
---|
401 | </section> |
---|
402 | |
---|
403 | <section title="Protection Space (Realm)" anchor="protection.space"> |
---|
404 | <iref item="Protection Space"/> |
---|
405 | <iref item="Realm"/> |
---|
406 | <t> |
---|
407 | The authentication parameter realm is reserved for use by authentication |
---|
408 | schemes that wish to indicate the scope of protection. |
---|
409 | </t> |
---|
410 | <t> |
---|
411 | A protection space is defined by the canonical root URI (the |
---|
412 | scheme and authority components of the effective request URI; see |
---|
413 | Section 4.3 of <xref target="Part1"/>) of the |
---|
414 | server being accessed, in combination with the realm value if present. |
---|
415 | These realms allow the protected resources on a server to be |
---|
416 | partitioned into a set of protection spaces, each with its own |
---|
417 | authentication scheme and/or authorization database. The realm value |
---|
418 | is a string, generally assigned by the origin server, which can have |
---|
419 | additional semantics specific to the authentication scheme. Note that |
---|
420 | there can be multiple challenges with the same auth-scheme but |
---|
421 | different realms. |
---|
422 | </t> |
---|
423 | <t> |
---|
424 | The protection space determines the domain over which credentials can |
---|
425 | be automatically applied. If a prior request has been authorized, the |
---|
426 | same credentials MAY be reused for all other requests within that |
---|
427 | protection space for a period of time determined by the |
---|
428 | authentication scheme, parameters, and/or user preference. Unless |
---|
429 | otherwise defined by the authentication scheme, a single protection |
---|
430 | space cannot extend outside the scope of its server. |
---|
431 | </t> |
---|
432 | <t> |
---|
433 | For historical reasons, senders MUST only use the quoted-string syntax. |
---|
434 | Recipients might have to support both token and quoted-string syntax for |
---|
435 | maximum interoperability with existing clients that have been accepting both |
---|
436 | notations for a long time. |
---|
437 | </t> |
---|
438 | </section> |
---|
439 | |
---|
440 | <section title="Authentication Scheme Registry" anchor="authentication.scheme.registry"> |
---|
441 | <t> |
---|
442 | The HTTP Authentication Scheme Registry defines the name space for the |
---|
443 | authentication schemes in challenges and credentials. |
---|
444 | </t> |
---|
445 | <t> |
---|
446 | Registrations MUST include the following fields: |
---|
447 | <list style="symbols"> |
---|
448 | <t>Authentication Scheme Name</t> |
---|
449 | <t>Pointer to specification text</t> |
---|
450 | <t>Notes (optional)</t> |
---|
451 | </list> |
---|
452 | </t> |
---|
453 | <t> |
---|
454 | Values to be added to this name space are subject to IETF review |
---|
455 | (<xref target="RFC5226"/>, Section 4.1). |
---|
456 | </t> |
---|
457 | <t> |
---|
458 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>. |
---|
459 | </t> |
---|
460 | |
---|
461 | <section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes"> |
---|
462 | <t> |
---|
463 | There are certain aspects of the HTTP Authentication Framework that put |
---|
464 | constraints on how new authentication schemes can work: |
---|
465 | </t> |
---|
466 | <t> |
---|
467 | <list style="symbols"> |
---|
468 | <t> |
---|
469 | Authentication schemes need to be compatible with the inherent |
---|
470 | constraints of HTTP; for instance, that messages need to keep their |
---|
471 | semantics when inspected in isolation, thus an authentication scheme |
---|
472 | can not bind information to the TCP session over which the message |
---|
473 | was received (see Section 2.2 of <xref target="Part1"/>). |
---|
474 | </t> |
---|
475 | <t> |
---|
476 | The authentication parameter "realm" is reserved for defining Protection |
---|
477 | Spaces as defined in <xref target="protection.space"/>. New schemes |
---|
478 | MUST NOT use it in a way incompatible with that definition. |
---|
479 | </t> |
---|
480 | <t> |
---|
481 | The "b64token" notation was introduced for compatibility with existing |
---|
482 | authentication schemes and can only be used once per challenge/credentials. |
---|
483 | New schemes thus ought to use the "auth-param" syntax instead, because |
---|
484 | otherwise future extensions will be impossible. |
---|
485 | </t> |
---|
486 | <t> |
---|
487 | The parsing of challenges and credentials is defined by this specification, |
---|
488 | and cannot be modified by new authentication schemes. When the auth-param |
---|
489 | syntax is used, all parameters ought to support both token and |
---|
490 | quoted-string syntax, and syntactical constraints ought to be defined on |
---|
491 | the field value after parsing (i.e., quoted-string processing). This is |
---|
492 | necessary so that recipients can use a generic parser that applies to |
---|
493 | all authentication schemes. |
---|
494 | <vspace blankLines="1"/> |
---|
495 | Note: the fact that the value syntax for the "realm" parameter |
---|
496 | is restricted to quoted-string was a bad design choice not to be repeated |
---|
497 | for new parameters. |
---|
498 | </t> |
---|
499 | <t> |
---|
500 | Authentication schemes need to document whether they are usable in |
---|
501 | origin-server authentication (i.e., using WWW-Authenticate), and/or |
---|
502 | proxy authentication (i.e., using Proxy-Authenticate). |
---|
503 | </t> |
---|
504 | <t> |
---|
505 | The credentials carried in an Authorization header field are specific to |
---|
506 | the User Agent, and therefore have the same effect on HTTP caches as the |
---|
507 | "private" Cache-Control response directive, within the scope of the |
---|
508 | request they appear in. |
---|
509 | <vspace blankLines="1"/> |
---|
510 | Therefore, new authentication schemes which choose not to carry |
---|
511 | credentials in the Authorization header (e.g., using a newly defined |
---|
512 | header) will need to explicitly disallow caching, by mandating the use of |
---|
513 | either Cache-Control request directives (e.g., "no-store") or response |
---|
514 | directives (e.g., "private"). |
---|
515 | </t> |
---|
516 | </list> |
---|
517 | </t> |
---|
518 | </section> |
---|
519 | |
---|
520 | </section> |
---|
521 | |
---|
522 | </section> |
---|
523 | |
---|
524 | <section title="Status Code Definitions" anchor="status.code.definitions"> |
---|
525 | <section title="401 Unauthorized" anchor="status.401"> |
---|
526 | <iref primary="true" item="401 Unauthorized (status code)"/> |
---|
527 | <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/> |
---|
528 | <t> |
---|
529 | The request requires user authentication. The response MUST include a |
---|
530 | WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge |
---|
531 | applicable to the target resource. The client MAY repeat the |
---|
532 | request with a suitable Authorization header field (<xref target="header.authorization"/>). If |
---|
533 | the request already included Authorization credentials, then the 401 |
---|
534 | response indicates that authorization has been refused for those |
---|
535 | credentials. If the 401 response contains the same challenge as the |
---|
536 | prior response, and the user agent has already attempted |
---|
537 | authentication at least once, then the user SHOULD be presented the |
---|
538 | representation that was given in the response, since that representation might |
---|
539 | include relevant diagnostic information. |
---|
540 | </t> |
---|
541 | </section> |
---|
542 | <section title="407 Proxy Authentication Required" anchor="status.407"> |
---|
543 | <iref primary="true" item="407 Proxy Authentication Required (status code)"/> |
---|
544 | <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/> |
---|
545 | <t> |
---|
546 | This code is similar to 401 (Unauthorized), but indicates that the |
---|
547 | client ought to first authenticate itself with the proxy. The proxy MUST |
---|
548 | return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a |
---|
549 | challenge applicable to the proxy for the target resource. The |
---|
550 | client MAY repeat the request with a suitable Proxy-Authorization |
---|
551 | header field (<xref target="header.proxy-authorization"/>). |
---|
552 | </t> |
---|
553 | </section> |
---|
554 | </section> |
---|
555 | |
---|
556 | <section title="Header Field Definitions" anchor="header.field.definitions"> |
---|
557 | <t> |
---|
558 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
559 | related to authentication. |
---|
560 | </t> |
---|
561 | |
---|
562 | <section title="Authorization" anchor="header.authorization"> |
---|
563 | <iref primary="true" item="Authorization header field"/> |
---|
564 | <iref primary="true" item="Header Fields" subitem="Authorization"/> |
---|
565 | |
---|
566 | <t> |
---|
567 | The "Authorization" header field allows a user agent to authenticate |
---|
568 | itself with a server — usually, but not necessarily, after receiving a 401 |
---|
569 | (Unauthorized) response. Its value consists of credentials containing |
---|
570 | information of the user agent for the realm of the resource being |
---|
571 | requested. |
---|
572 | </t> |
---|
573 | <figure><iref primary="true" item="Grammar" subitem="Authorization"/><artwork type="abnf2616"><![CDATA[ |
---|
574 | Authorization = credentials |
---|
575 | ]]></artwork></figure> |
---|
576 | <t> |
---|
577 | If a request is |
---|
578 | authenticated and a realm specified, the same credentials SHOULD |
---|
579 | be valid for all other requests within this realm (assuming that |
---|
580 | the authentication scheme itself does not require otherwise, such |
---|
581 | as credentials that vary according to a challenge value or using |
---|
582 | synchronized clocks). |
---|
583 | </t> |
---|
584 | <t> |
---|
585 | When a shared cache (see Section 1.2 of <xref target="Part6"/>) receives a request |
---|
586 | containing an Authorization field, it MUST NOT return the |
---|
587 | corresponding response as a reply to any other request, unless one |
---|
588 | of the following specific exceptions holds: |
---|
589 | </t> |
---|
590 | <t> |
---|
591 | <list style="numbers"> |
---|
592 | <t>If the response includes the "s-maxage" cache-control |
---|
593 | directive, the cache MAY use that response in replying to a |
---|
594 | subsequent request. But (if the specified maximum age has |
---|
595 | passed) a proxy cache MUST first revalidate it with the origin |
---|
596 | server, using the header fields from the new request to allow |
---|
597 | the origin server to authenticate the new request. (This is the |
---|
598 | defined behavior for s-maxage.) If the response includes "s-maxage=0", |
---|
599 | the proxy MUST always revalidate it before re-using |
---|
600 | it.</t> |
---|
601 | |
---|
602 | <t>If the response includes the "must-revalidate" cache-control |
---|
603 | directive, the cache MAY use that response in replying to a |
---|
604 | subsequent request. But if the response is stale, all caches |
---|
605 | MUST first revalidate it with the origin server, using the |
---|
606 | header fields from the new request to allow the origin server |
---|
607 | to authenticate the new request.</t> |
---|
608 | |
---|
609 | <t>If the response includes the "public" cache-control directive, |
---|
610 | it MAY be returned in reply to any subsequent request.</t> |
---|
611 | </list> |
---|
612 | </t> |
---|
613 | </section> |
---|
614 | |
---|
615 | <section title="Proxy-Authenticate" anchor="header.proxy-authenticate"> |
---|
616 | <iref primary="true" item="Proxy-Authenticate header field"/> |
---|
617 | <iref primary="true" item="Header Fields" subitem="Proxy-Authenticate"/> |
---|
618 | |
---|
619 | <t> |
---|
620 | The "Proxy-Authenticate" header field consists of a challenge that |
---|
621 | indicates the authentication scheme and parameters applicable to the proxy |
---|
622 | for this effective request URI (Section 4.3 of <xref target="Part1"/>). It MUST be included as part |
---|
623 | of a 407 (Proxy Authentication Required) response. |
---|
624 | </t> |
---|
625 | <figure><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><artwork type="abnf2616"><![CDATA[ |
---|
626 | Proxy-Authenticate = 1#challenge |
---|
627 | ]]></artwork></figure> |
---|
628 | <t> |
---|
629 | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to |
---|
630 | the current connection and SHOULD NOT be passed on to downstream |
---|
631 | clients. However, an intermediate proxy might need to obtain its own |
---|
632 | credentials by requesting them from the downstream client, which in |
---|
633 | some circumstances will appear as if the proxy is forwarding the |
---|
634 | Proxy-Authenticate header field. |
---|
635 | </t> |
---|
636 | </section> |
---|
637 | |
---|
638 | <section title="Proxy-Authorization" anchor="header.proxy-authorization"> |
---|
639 | <iref primary="true" item="Proxy-Authorization header field"/> |
---|
640 | <iref primary="true" item="Header Fields" subitem="Proxy-Authorization"/> |
---|
641 | |
---|
642 | <t> |
---|
643 | The "Proxy-Authorization" header field allows the client to |
---|
644 | identify itself (or its user) to a proxy which requires |
---|
645 | authentication. Its value consists of |
---|
646 | credentials containing the authentication information of the user |
---|
647 | agent for the proxy and/or realm of the resource being requested. |
---|
648 | </t> |
---|
649 | <figure><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><artwork type="abnf2616"><![CDATA[ |
---|
650 | Proxy-Authorization = credentials |
---|
651 | ]]></artwork></figure> |
---|
652 | <t> |
---|
653 | Unlike Authorization, the Proxy-Authorization header field applies only to |
---|
654 | the next outbound proxy that demanded authentication using the Proxy-Authenticate |
---|
655 | field. When multiple proxies are used in a chain, the |
---|
656 | Proxy-Authorization header field is consumed by the first outbound |
---|
657 | proxy that was expecting to receive credentials. A proxy MAY relay |
---|
658 | the credentials from the client request to the next proxy if that is |
---|
659 | the mechanism by which the proxies cooperatively authenticate a given |
---|
660 | request. |
---|
661 | </t> |
---|
662 | </section> |
---|
663 | |
---|
664 | <section title="WWW-Authenticate" anchor="header.www-authenticate"> |
---|
665 | <iref primary="true" item="WWW-Authenticate header field"/> |
---|
666 | <iref primary="true" item="Header Fields" subitem="WWW-Authenticate"/> |
---|
667 | |
---|
668 | <t> |
---|
669 | The "WWW-Authenticate" header field consists of at least one |
---|
670 | challenge that indicates the authentication scheme(s) and parameters |
---|
671 | applicable to the effective request URI (Section 4.3 of <xref target="Part1"/>). |
---|
672 | </t> |
---|
673 | <t> |
---|
674 | It MUST be included in 401 (Unauthorized) response messages and MAY be |
---|
675 | included in other response messages to indicate that supplying credentials |
---|
676 | (or different credentials) might affect the response. |
---|
677 | </t> |
---|
678 | <figure><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><artwork type="abnf2616"><![CDATA[ |
---|
679 | WWW-Authenticate = 1#challenge |
---|
680 | ]]></artwork></figure> |
---|
681 | <t> |
---|
682 | User agents are advised to take special care in parsing the WWW-Authenticate |
---|
683 | field value as it might contain more than one challenge, |
---|
684 | or if more than one WWW-Authenticate header field is provided, the |
---|
685 | contents of a challenge itself can contain a comma-separated list of |
---|
686 | authentication parameters. |
---|
687 | </t> |
---|
688 | <figure> |
---|
689 | <preamble>For instance:</preamble> |
---|
690 | <artwork type="example"><![CDATA[ |
---|
691 | WWW-Authenticate: Newauth realm="apps", type=1, |
---|
692 | title="Login to \"apps\"", Basic realm="simple" |
---|
693 | ]]></artwork> |
---|
694 | <postamble> |
---|
695 | This header field contains two challenges; one for the "Newauth" scheme |
---|
696 | with a realm value of "apps", and two additional parameters "type" and |
---|
697 | "title", and another one for the "Basic" scheme with a realm value of "simple". |
---|
698 | </postamble></figure> |
---|
699 | </section> |
---|
700 | |
---|
701 | </section> |
---|
702 | |
---|
703 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
704 | |
---|
705 | <section title="Authenticaton Scheme Registry" anchor="authentication.scheme.registration"> |
---|
706 | <t> |
---|
707 | The registration procedure for HTTP Authentication Schemes is defined by |
---|
708 | <xref target="authentication.scheme.registry"/> of this document. |
---|
709 | </t> |
---|
710 | <t> |
---|
711 | The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>. |
---|
712 | </t> |
---|
713 | </section> |
---|
714 | |
---|
715 | <section title="Status Code Registration" anchor="status.code.registration"> |
---|
716 | <t> |
---|
717 | The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> |
---|
718 | shall be updated with the registrations below: |
---|
719 | </t> |
---|
720 | |
---|
721 | <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> |
---|
722 | <texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table"> |
---|
723 | <ttcol>Value</ttcol> |
---|
724 | <ttcol>Description</ttcol> |
---|
725 | <ttcol>Reference</ttcol> |
---|
726 | <c>401</c> |
---|
727 | <c>Unauthorized</c> |
---|
728 | <c> |
---|
729 | <xref target="status.401"/> |
---|
730 | </c> |
---|
731 | <c>407</c> |
---|
732 | <c>Proxy Authentication Required</c> |
---|
733 | <c> |
---|
734 | <xref target="status.407"/> |
---|
735 | </c> |
---|
736 | </texttable> |
---|
737 | <!--(END)--> |
---|
738 | |
---|
739 | </section> |
---|
740 | |
---|
741 | <section title="Header Field Registration" anchor="header.field.registration"> |
---|
742 | <t> |
---|
743 | The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated |
---|
744 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
745 | </t> |
---|
746 | |
---|
747 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
748 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
749 | <ttcol>Header Field Name</ttcol> |
---|
750 | <ttcol>Protocol</ttcol> |
---|
751 | <ttcol>Status</ttcol> |
---|
752 | <ttcol>Reference</ttcol> |
---|
753 | |
---|
754 | <c>Authorization</c> |
---|
755 | <c>http</c> |
---|
756 | <c>standard</c> |
---|
757 | <c> |
---|
758 | <xref target="header.authorization"/> |
---|
759 | </c> |
---|
760 | <c>Proxy-Authenticate</c> |
---|
761 | <c>http</c> |
---|
762 | <c>standard</c> |
---|
763 | <c> |
---|
764 | <xref target="header.proxy-authenticate"/> |
---|
765 | </c> |
---|
766 | <c>Proxy-Authorization</c> |
---|
767 | <c>http</c> |
---|
768 | <c>standard</c> |
---|
769 | <c> |
---|
770 | <xref target="header.proxy-authorization"/> |
---|
771 | </c> |
---|
772 | <c>WWW-Authenticate</c> |
---|
773 | <c>http</c> |
---|
774 | <c>standard</c> |
---|
775 | <c> |
---|
776 | <xref target="header.www-authenticate"/> |
---|
777 | </c> |
---|
778 | </texttable> |
---|
779 | <!--(END)--> |
---|
780 | |
---|
781 | <t> |
---|
782 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
783 | </t> |
---|
784 | </section> |
---|
785 | </section> |
---|
786 | |
---|
787 | <section title="Security Considerations" anchor="security.considerations"> |
---|
788 | <t> |
---|
789 | This section is meant to inform application developers, information |
---|
790 | providers, and users of the security limitations in HTTP/1.1 as |
---|
791 | described by this document. The discussion does not include |
---|
792 | definitive solutions to the problems revealed, though it does make |
---|
793 | some suggestions for reducing security risks. |
---|
794 | </t> |
---|
795 | |
---|
796 | <section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients"> |
---|
797 | <t> |
---|
798 | Existing HTTP clients and user agents typically retain authentication |
---|
799 | information indefinitely. HTTP/1.1 does not provide a method for a |
---|
800 | server to direct clients to discard these cached credentials. This is |
---|
801 | a significant defect that requires further extensions to HTTP. |
---|
802 | Circumstances under which credential caching can interfere with the |
---|
803 | application's security model include but are not limited to: |
---|
804 | <list style="symbols"> |
---|
805 | <t>Clients which have been idle for an extended period following |
---|
806 | which the server might wish to cause the client to reprompt the |
---|
807 | user for credentials.</t> |
---|
808 | |
---|
809 | <t>Applications which include a session termination indication |
---|
810 | (such as a "logout" or "commit" button on a page) after which |
---|
811 | the server side of the application "knows" that there is no |
---|
812 | further reason for the client to retain the credentials.</t> |
---|
813 | </list> |
---|
814 | </t> |
---|
815 | <t> |
---|
816 | This is currently under separate study. There are a number of work-arounds |
---|
817 | to parts of this problem, and we encourage the use of |
---|
818 | password protection in screen savers, idle time-outs, and other |
---|
819 | methods which mitigate the security problems inherent in this |
---|
820 | problem. In particular, user agents which cache credentials are |
---|
821 | encouraged to provide a readily accessible mechanism for discarding |
---|
822 | cached credentials under user control. |
---|
823 | </t> |
---|
824 | </section> |
---|
825 | </section> |
---|
826 | |
---|
827 | <section title="Acknowledgments" anchor="acks"> |
---|
828 | <t> |
---|
829 | This specification takes over the definition of the HTTP Authentication |
---|
830 | Framework, previously defined in RFC 2617. |
---|
831 | We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, |
---|
832 | Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work |
---|
833 | on that specification. See Section 6 of <xref target="RFC2617"/> |
---|
834 | for further acknowledgements. |
---|
835 | </t> |
---|
836 | <t> |
---|
837 | See Section 11 of <xref target="Part1"/> for the Acknowledgments related to this document revision. |
---|
838 | </t> |
---|
839 | </section> |
---|
840 | </middle> |
---|
841 | |
---|
842 | <back> |
---|
843 | |
---|
844 | <references title="Normative References"> |
---|
845 | |
---|
846 | <reference anchor="Part1"> |
---|
847 | <front> |
---|
848 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
849 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
850 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
851 | <address><email>fielding@gbiv.com</email></address> |
---|
852 | </author> |
---|
853 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
854 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
855 | <address><email>jg@freedesktop.org</email></address> |
---|
856 | </author> |
---|
857 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
858 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
859 | <address><email>JeffMogul@acm.org</email></address> |
---|
860 | </author> |
---|
861 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
862 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
863 | <address><email>henrikn@microsoft.com</email></address> |
---|
864 | </author> |
---|
865 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
866 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
867 | <address><email>LMM@acm.org</email></address> |
---|
868 | </author> |
---|
869 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
870 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
871 | <address><email>paulle@microsoft.com</email></address> |
---|
872 | </author> |
---|
873 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
874 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
875 | <address><email>timbl@w3.org</email></address> |
---|
876 | </author> |
---|
877 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
878 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
879 | <address><email>ylafon@w3.org</email></address> |
---|
880 | </author> |
---|
881 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
882 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
883 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
884 | </author> |
---|
885 | <date month="January" year="2012"/> |
---|
886 | </front> |
---|
887 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-18"/> |
---|
888 | |
---|
889 | </reference> |
---|
890 | |
---|
891 | <reference anchor="Part6"> |
---|
892 | <front> |
---|
893 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
894 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
895 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
896 | <address><email>fielding@gbiv.com</email></address> |
---|
897 | </author> |
---|
898 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
899 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
900 | <address><email>jg@freedesktop.org</email></address> |
---|
901 | </author> |
---|
902 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
903 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
904 | <address><email>JeffMogul@acm.org</email></address> |
---|
905 | </author> |
---|
906 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
907 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
908 | <address><email>henrikn@microsoft.com</email></address> |
---|
909 | </author> |
---|
910 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
911 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
912 | <address><email>LMM@acm.org</email></address> |
---|
913 | </author> |
---|
914 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
915 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
916 | <address><email>paulle@microsoft.com</email></address> |
---|
917 | </author> |
---|
918 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
919 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
920 | <address><email>timbl@w3.org</email></address> |
---|
921 | </author> |
---|
922 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
923 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
924 | <address><email>ylafon@w3.org</email></address> |
---|
925 | </author> |
---|
926 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
927 | <organization>Rackspace</organization> |
---|
928 | <address><email>mnot@mnot.net</email></address> |
---|
929 | </author> |
---|
930 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
931 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
932 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
933 | </author> |
---|
934 | <date month="January" year="2012"/> |
---|
935 | </front> |
---|
936 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-18"/> |
---|
937 | |
---|
938 | </reference> |
---|
939 | |
---|
940 | <reference anchor="RFC2119"> |
---|
941 | <front> |
---|
942 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
943 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
944 | <organization>Harvard University</organization> |
---|
945 | <address><email>sob@harvard.edu</email></address> |
---|
946 | </author> |
---|
947 | <date month="March" year="1997"/> |
---|
948 | </front> |
---|
949 | <seriesInfo name="BCP" value="14"/> |
---|
950 | <seriesInfo name="RFC" value="2119"/> |
---|
951 | </reference> |
---|
952 | |
---|
953 | <reference anchor="RFC5234"> |
---|
954 | <front> |
---|
955 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
956 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
957 | <organization>Brandenburg InternetWorking</organization> |
---|
958 | <address> |
---|
959 | <email>dcrocker@bbiw.net</email> |
---|
960 | </address> |
---|
961 | </author> |
---|
962 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
963 | <organization>THUS plc.</organization> |
---|
964 | <address> |
---|
965 | <email>paul.overell@thus.net</email> |
---|
966 | </address> |
---|
967 | </author> |
---|
968 | <date month="January" year="2008"/> |
---|
969 | </front> |
---|
970 | <seriesInfo name="STD" value="68"/> |
---|
971 | <seriesInfo name="RFC" value="5234"/> |
---|
972 | </reference> |
---|
973 | |
---|
974 | </references> |
---|
975 | |
---|
976 | <references title="Informative References"> |
---|
977 | |
---|
978 | <reference anchor="RFC2616"> |
---|
979 | <front> |
---|
980 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
981 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
982 | <organization>University of California, Irvine</organization> |
---|
983 | <address><email>fielding@ics.uci.edu</email></address> |
---|
984 | </author> |
---|
985 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
986 | <organization>W3C</organization> |
---|
987 | <address><email>jg@w3.org</email></address> |
---|
988 | </author> |
---|
989 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
990 | <organization>Compaq Computer Corporation</organization> |
---|
991 | <address><email>mogul@wrl.dec.com</email></address> |
---|
992 | </author> |
---|
993 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
994 | <organization>MIT Laboratory for Computer Science</organization> |
---|
995 | <address><email>frystyk@w3.org</email></address> |
---|
996 | </author> |
---|
997 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
998 | <organization>Xerox Corporation</organization> |
---|
999 | <address><email>masinter@parc.xerox.com</email></address> |
---|
1000 | </author> |
---|
1001 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
1002 | <organization>Microsoft Corporation</organization> |
---|
1003 | <address><email>paulle@microsoft.com</email></address> |
---|
1004 | </author> |
---|
1005 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
1006 | <organization>W3C</organization> |
---|
1007 | <address><email>timbl@w3.org</email></address> |
---|
1008 | </author> |
---|
1009 | <date month="June" year="1999"/> |
---|
1010 | </front> |
---|
1011 | <seriesInfo name="RFC" value="2616"/> |
---|
1012 | </reference> |
---|
1013 | |
---|
1014 | <reference anchor="RFC2617"> |
---|
1015 | <front> |
---|
1016 | <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> |
---|
1017 | <author initials="J." surname="Franks" fullname="John Franks"> |
---|
1018 | <organization>Northwestern University, Department of Mathematics</organization> |
---|
1019 | <address><email>john@math.nwu.edu</email></address> |
---|
1020 | </author> |
---|
1021 | <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> |
---|
1022 | <organization>Verisign Inc.</organization> |
---|
1023 | <address><email>pbaker@verisign.com</email></address> |
---|
1024 | </author> |
---|
1025 | <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> |
---|
1026 | <organization>AbiSource, Inc.</organization> |
---|
1027 | <address><email>jeff@AbiSource.com</email></address> |
---|
1028 | </author> |
---|
1029 | <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> |
---|
1030 | <organization>Agranat Systems, Inc.</organization> |
---|
1031 | <address><email>lawrence@agranat.com</email></address> |
---|
1032 | </author> |
---|
1033 | <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> |
---|
1034 | <organization>Microsoft Corporation</organization> |
---|
1035 | <address><email>paulle@microsoft.com</email></address> |
---|
1036 | </author> |
---|
1037 | <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> |
---|
1038 | <organization>Netscape Communications Corporation</organization> |
---|
1039 | </author> |
---|
1040 | <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> |
---|
1041 | <organization>Open Market, Inc.</organization> |
---|
1042 | <address><email>stewart@OpenMarket.com</email></address> |
---|
1043 | </author> |
---|
1044 | <date month="June" year="1999"/> |
---|
1045 | </front> |
---|
1046 | <seriesInfo name="RFC" value="2617"/> |
---|
1047 | </reference> |
---|
1048 | |
---|
1049 | <reference anchor="RFC3864"> |
---|
1050 | <front> |
---|
1051 | <title>Registration Procedures for Message Header Fields</title> |
---|
1052 | <author initials="G." surname="Klyne" fullname="G. Klyne"> |
---|
1053 | <organization>Nine by Nine</organization> |
---|
1054 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
1055 | </author> |
---|
1056 | <author initials="M." surname="Nottingham" fullname="M. Nottingham"> |
---|
1057 | <organization>BEA Systems</organization> |
---|
1058 | <address><email>mnot@pobox.com</email></address> |
---|
1059 | </author> |
---|
1060 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
1061 | <organization>HP Labs</organization> |
---|
1062 | <address><email>JeffMogul@acm.org</email></address> |
---|
1063 | </author> |
---|
1064 | <date year="2004" month="September"/> |
---|
1065 | </front> |
---|
1066 | <seriesInfo name="BCP" value="90"/> |
---|
1067 | <seriesInfo name="RFC" value="3864"/> |
---|
1068 | </reference> |
---|
1069 | |
---|
1070 | <reference anchor="RFC3986"> |
---|
1071 | <front> |
---|
1072 | <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title> |
---|
1073 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1074 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1075 | <address> |
---|
1076 | <email>timbl@w3.org</email> |
---|
1077 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
1078 | </address> |
---|
1079 | </author> |
---|
1080 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
1081 | <organization abbrev="Day Software">Day Software</organization> |
---|
1082 | <address> |
---|
1083 | <email>fielding@gbiv.com</email> |
---|
1084 | <uri>http://roy.gbiv.com/</uri> |
---|
1085 | </address> |
---|
1086 | </author> |
---|
1087 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1088 | <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> |
---|
1089 | <address> |
---|
1090 | <email>LMM@acm.org</email> |
---|
1091 | <uri>http://larry.masinter.net/</uri> |
---|
1092 | </address> |
---|
1093 | </author> |
---|
1094 | <date month="January" year="2005"/> |
---|
1095 | </front> |
---|
1096 | <seriesInfo name="STD" value="66"/> |
---|
1097 | <seriesInfo name="RFC" value="3986"/> |
---|
1098 | </reference> |
---|
1099 | |
---|
1100 | <reference anchor="RFC4648"> |
---|
1101 | <front> |
---|
1102 | <title>The Base16, Base32, and Base64 Data Encodings</title> |
---|
1103 | <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> |
---|
1104 | <date year="2006" month="October"/> |
---|
1105 | </front> |
---|
1106 | <seriesInfo value="4648" name="RFC"/> |
---|
1107 | </reference> |
---|
1108 | |
---|
1109 | <reference anchor="RFC5226"> |
---|
1110 | <front> |
---|
1111 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
1112 | <author initials="T." surname="Narten" fullname="T. Narten"> |
---|
1113 | <organization>IBM</organization> |
---|
1114 | <address><email>narten@us.ibm.com</email></address> |
---|
1115 | </author> |
---|
1116 | <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> |
---|
1117 | <organization>Google</organization> |
---|
1118 | <address><email>Harald@Alvestrand.no</email></address> |
---|
1119 | </author> |
---|
1120 | <date year="2008" month="May"/> |
---|
1121 | </front> |
---|
1122 | <seriesInfo name="BCP" value="26"/> |
---|
1123 | <seriesInfo name="RFC" value="5226"/> |
---|
1124 | </reference> |
---|
1125 | |
---|
1126 | </references> |
---|
1127 | |
---|
1128 | <section title="Changes from RFCs 2616 and 2617" anchor="changes.from.rfc.2616"> |
---|
1129 | <t> |
---|
1130 | The "realm" parameter isn't required anymore in general; consequently, the |
---|
1131 | ABNF allows challenges without any auth parameters. |
---|
1132 | (<xref target="access.authentication.framework"/>) |
---|
1133 | </t> |
---|
1134 | <t> |
---|
1135 | The "b64token" alternative to auth-param lists has been added for consistency |
---|
1136 | with legacy authentication schemes such as "Basic". |
---|
1137 | (<xref target="access.authentication.framework"/>) |
---|
1138 | </t> |
---|
1139 | <t> |
---|
1140 | Change ABNF productions for header fields to only define the field value. |
---|
1141 | (<xref target="header.field.definitions"/>) |
---|
1142 | </t> |
---|
1143 | </section> |
---|
1144 | |
---|
1145 | |
---|
1146 | <section title="Collected ABNF" anchor="collected.abnf"> |
---|
1147 | <figure> |
---|
1148 | <artwork type="abnf" name="p7-auth.parsed-abnf"><![CDATA[ |
---|
1149 | Authorization = credentials |
---|
1150 | |
---|
1151 | BWS = <BWS, defined in [Part1], Section 1.2.2> |
---|
1152 | |
---|
1153 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
1154 | |
---|
1155 | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS |
---|
1156 | challenge ] ) |
---|
1157 | Proxy-Authorization = credentials |
---|
1158 | |
---|
1159 | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge |
---|
1160 | ] ) |
---|
1161 | |
---|
1162 | auth-param = token BWS "=" BWS ( token / quoted-string ) |
---|
1163 | auth-scheme = token |
---|
1164 | |
---|
1165 | b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) |
---|
1166 | *"=" |
---|
1167 | |
---|
1168 | challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *( |
---|
1169 | OWS "," [ OWS auth-param ] ) ] ) ] |
---|
1170 | credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) |
---|
1171 | *( OWS "," [ OWS auth-param ] ) ] ) ] |
---|
1172 | |
---|
1173 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
---|
1174 | |
---|
1175 | token = <token, defined in [Part1], Section 3.2.3> |
---|
1176 | ]]></artwork> |
---|
1177 | </figure> |
---|
1178 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[ |
---|
1179 | ; Authorization defined but not used |
---|
1180 | ; Proxy-Authenticate defined but not used |
---|
1181 | ; Proxy-Authorization defined but not used |
---|
1182 | ; WWW-Authenticate defined but not used |
---|
1183 | ]]></artwork></figure></section> |
---|
1184 | |
---|
1185 | |
---|
1186 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
1187 | |
---|
1188 | <section title="Since RFC 2616"> |
---|
1189 | <t> |
---|
1190 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
1191 | </t> |
---|
1192 | </section> |
---|
1193 | |
---|
1194 | <section title="Since draft-ietf-httpbis-p7-auth-00"> |
---|
1195 | <t> |
---|
1196 | Closed issues: |
---|
1197 | <list style="symbols"> |
---|
1198 | <t> |
---|
1199 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
1200 | "Normative and Informative references" |
---|
1201 | </t> |
---|
1202 | </list> |
---|
1203 | </t> |
---|
1204 | </section> |
---|
1205 | |
---|
1206 | <section title="Since draft-ietf-httpbis-p7-auth-01"> |
---|
1207 | <t> |
---|
1208 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1209 | <list style="symbols"> |
---|
1210 | <t> |
---|
1211 | Explicitly import BNF rules for "challenge" and "credentials" from RFC2617. |
---|
1212 | </t> |
---|
1213 | <t> |
---|
1214 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
1215 | </t> |
---|
1216 | </list> |
---|
1217 | </t> |
---|
1218 | </section> |
---|
1219 | |
---|
1220 | <section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02"> |
---|
1221 | <t> |
---|
1222 | Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
1223 | <list style="symbols"> |
---|
1224 | <t> |
---|
1225 | Reference RFC 3984, and update header field registrations for header fields defined |
---|
1226 | in this document. |
---|
1227 | </t> |
---|
1228 | </list> |
---|
1229 | </t> |
---|
1230 | </section> |
---|
1231 | |
---|
1232 | <section title="Since draft-ietf-httpbis-p7-auth-03" anchor="changes.since.03"> |
---|
1233 | <t> |
---|
1234 | None. |
---|
1235 | </t> |
---|
1236 | </section> |
---|
1237 | |
---|
1238 | <section title="Since draft-ietf-httpbis-p7-auth-04" anchor="changes.since.04"> |
---|
1239 | <t> |
---|
1240 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1241 | <list style="symbols"> |
---|
1242 | <t> |
---|
1243 | Use "/" instead of "|" for alternatives. |
---|
1244 | </t> |
---|
1245 | <t> |
---|
1246 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
1247 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
1248 | </t> |
---|
1249 | <t> |
---|
1250 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
1251 | header field value format definitions. |
---|
1252 | </t> |
---|
1253 | </list> |
---|
1254 | </t> |
---|
1255 | </section> |
---|
1256 | |
---|
1257 | <section title="Since draft-ietf-httpbis-p7-auth-05" anchor="changes.since.05"> |
---|
1258 | <t> |
---|
1259 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
1260 | <list style="symbols"> |
---|
1261 | <t> |
---|
1262 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
1263 | </t> |
---|
1264 | </list> |
---|
1265 | </t> |
---|
1266 | </section> |
---|
1267 | |
---|
1268 | <section title="Since draft-ietf-httpbis-p7-auth-06" anchor="changes.since.06"> |
---|
1269 | <t> |
---|
1270 | None. |
---|
1271 | </t> |
---|
1272 | </section> |
---|
1273 | |
---|
1274 | <section title="Since draft-ietf-httpbis-p7-auth-07" anchor="changes.since.07"> |
---|
1275 | <t> |
---|
1276 | Closed issues: |
---|
1277 | <list style="symbols"> |
---|
1278 | <t> |
---|
1279 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>: |
---|
1280 | "move IANA registrations for optional status codes" |
---|
1281 | </t> |
---|
1282 | </list> |
---|
1283 | </t> |
---|
1284 | </section> |
---|
1285 | |
---|
1286 | <section title="Since draft-ietf-httpbis-p7-auth-08" anchor="changes.since.08"> |
---|
1287 | <t> |
---|
1288 | No significant changes. |
---|
1289 | </t> |
---|
1290 | </section> |
---|
1291 | |
---|
1292 | <section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09"> |
---|
1293 | <t> |
---|
1294 | Partly resolved issues: |
---|
1295 | <list style="symbols"> |
---|
1296 | <t> |
---|
1297 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: |
---|
1298 | "Term for the requested resource's URI" |
---|
1299 | </t> |
---|
1300 | </list> |
---|
1301 | </t> |
---|
1302 | </section> |
---|
1303 | |
---|
1304 | <section title="Since draft-ietf-httpbis-p7-auth-10" anchor="changes.since.10"> |
---|
1305 | <t> |
---|
1306 | None. |
---|
1307 | </t> |
---|
1308 | </section> |
---|
1309 | |
---|
1310 | <section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11"> |
---|
1311 | <t> |
---|
1312 | Closed issues: |
---|
1313 | <list style="symbols"> |
---|
1314 | <t> |
---|
1315 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/130"/>: |
---|
1316 | "introduction to part 7 is work-in-progress" |
---|
1317 | </t> |
---|
1318 | <t> |
---|
1319 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: |
---|
1320 | "auth-param syntax" |
---|
1321 | </t> |
---|
1322 | <t> |
---|
1323 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>: |
---|
1324 | "Header Classification" |
---|
1325 | </t> |
---|
1326 | <t> |
---|
1327 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>: |
---|
1328 | "absorbing the auth framework from 2617" |
---|
1329 | </t> |
---|
1330 | </list> |
---|
1331 | </t> |
---|
1332 | <t> |
---|
1333 | Partly resolved issues: |
---|
1334 | <list style="symbols"> |
---|
1335 | <t> |
---|
1336 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/141"/>: |
---|
1337 | "should we have an auth scheme registry" |
---|
1338 | </t> |
---|
1339 | </list> |
---|
1340 | </t> |
---|
1341 | </section> |
---|
1342 | |
---|
1343 | <section title="Since draft-ietf-httpbis-p7-auth-12" anchor="changes.since.12"> |
---|
1344 | <t> |
---|
1345 | None. |
---|
1346 | </t> |
---|
1347 | </section> |
---|
1348 | |
---|
1349 | <section title="Since draft-ietf-httpbis-p7-auth-13" anchor="changes.since.13"> |
---|
1350 | <t> |
---|
1351 | Closed issues: |
---|
1352 | <list style="symbols"> |
---|
1353 | <t> |
---|
1354 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>: |
---|
1355 | "untangle ABNFs for header fields" |
---|
1356 | </t> |
---|
1357 | </list> |
---|
1358 | </t> |
---|
1359 | </section> |
---|
1360 | |
---|
1361 | <section title="Since draft-ietf-httpbis-p7-auth-14" anchor="changes.since.14"> |
---|
1362 | <t> |
---|
1363 | None. |
---|
1364 | </t> |
---|
1365 | </section> |
---|
1366 | |
---|
1367 | <section title="Since draft-ietf-httpbis-p7-auth-15" anchor="changes.since.15"> |
---|
1368 | <t> |
---|
1369 | Closed issues: |
---|
1370 | <list style="symbols"> |
---|
1371 | <t> |
---|
1372 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/78"/>: |
---|
1373 | "Relationship between 401, Authorization and WWW-Authenticate" |
---|
1374 | </t> |
---|
1375 | <t> |
---|
1376 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/177"/>: |
---|
1377 | "Realm required on challenges" |
---|
1378 | </t> |
---|
1379 | <t> |
---|
1380 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: |
---|
1381 | "auth-param syntax" |
---|
1382 | </t> |
---|
1383 | <t> |
---|
1384 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/257"/>: |
---|
1385 | "Considerations for new authentications schemes" |
---|
1386 | </t> |
---|
1387 | <t> |
---|
1388 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/287"/>: |
---|
1389 | "LWS in auth-param ABNF" |
---|
1390 | </t> |
---|
1391 | <t> |
---|
1392 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/309"/>: |
---|
1393 | "credentials ABNF missing SP (still using implied LWS?)" |
---|
1394 | </t> |
---|
1395 | </list> |
---|
1396 | </t> |
---|
1397 | </section> |
---|
1398 | |
---|
1399 | <section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16"> |
---|
1400 | <t> |
---|
1401 | Closed issues: |
---|
1402 | <list style="symbols"> |
---|
1403 | <t> |
---|
1404 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: |
---|
1405 | "Document HTTP's error-handling philosophy" |
---|
1406 | </t> |
---|
1407 | <t> |
---|
1408 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/320"/>: |
---|
1409 | "add advice on defining auth scheme parameters" |
---|
1410 | </t> |
---|
1411 | </list> |
---|
1412 | </t> |
---|
1413 | </section> |
---|
1414 | |
---|
1415 | <section title="Since draft-ietf-httpbis-p7-auth-17" anchor="changes.since.17"> |
---|
1416 | <t> |
---|
1417 | Closed issues: |
---|
1418 | <list style="symbols"> |
---|
1419 | <t> |
---|
1420 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/314"/>: |
---|
1421 | "allow unquoted realm parameters" |
---|
1422 | </t> |
---|
1423 | <t> |
---|
1424 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/321"/>: |
---|
1425 | "Repeating auth-params" |
---|
1426 | </t> |
---|
1427 | </list> |
---|
1428 | </t> |
---|
1429 | </section> |
---|
1430 | |
---|
1431 | </section> |
---|
1432 | |
---|
1433 | </back> |
---|
1434 | </rfc> |
---|