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