1 |
|
---|
2 |
|
---|
3 |
|
---|
4 | Network Working Group R. Fielding, Ed.
|
---|
5 | Internet-Draft Day Software
|
---|
6 | Obsoletes: 2616 (if approved) J. Gettys
|
---|
7 | Updates: 2617 (if approved) One Laptop per Child
|
---|
8 | Intended status: Standards Track J. Mogul
|
---|
9 | Expires: May 20, 2009 HP
|
---|
10 | H. Frystyk
|
---|
11 | Microsoft
|
---|
12 | L. Masinter
|
---|
13 | Adobe Systems
|
---|
14 | P. Leach
|
---|
15 | Microsoft
|
---|
16 | T. Berners-Lee
|
---|
17 | W3C/MIT
|
---|
18 | Y. Lafon, Ed.
|
---|
19 | W3C
|
---|
20 | J. Reschke, Ed.
|
---|
21 | greenbytes
|
---|
22 | November 16, 2008
|
---|
23 |
|
---|
24 |
|
---|
25 | HTTP/1.1, part 7: Authentication
|
---|
26 | draft-ietf-httpbis-p7-auth-05
|
---|
27 |
|
---|
28 | Status of this Memo
|
---|
29 |
|
---|
30 | By submitting this Internet-Draft, each author represents that any
|
---|
31 | applicable patent or other IPR claims of which he or she is aware
|
---|
32 | have been or will be disclosed, and any of which he or she becomes
|
---|
33 | aware will be disclosed, in accordance with Section 6 of BCP 79.
|
---|
34 |
|
---|
35 | Internet-Drafts are working documents of the Internet Engineering
|
---|
36 | Task Force (IETF), its areas, and its working groups. Note that
|
---|
37 | other groups may also distribute working documents as Internet-
|
---|
38 | Drafts.
|
---|
39 |
|
---|
40 | Internet-Drafts are draft documents valid for a maximum of six months
|
---|
41 | and may be updated, replaced, or obsoleted by other documents at any
|
---|
42 | time. It is inappropriate to use Internet-Drafts as reference
|
---|
43 | material or to cite them other than as "work in progress."
|
---|
44 |
|
---|
45 | The list of current Internet-Drafts can be accessed at
|
---|
46 | http://www.ietf.org/ietf/1id-abstracts.txt.
|
---|
47 |
|
---|
48 | The list of Internet-Draft Shadow Directories can be accessed at
|
---|
49 | http://www.ietf.org/shadow.html.
|
---|
50 |
|
---|
51 | This Internet-Draft will expire on May 20, 2009.
|
---|
52 |
|
---|
53 |
|
---|
54 |
|
---|
55 | Fielding, et al. Expires May 20, 2009 [Page 1]
|
---|
56 |
|
---|
57 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
58 |
|
---|
59 |
|
---|
60 | Abstract
|
---|
61 |
|
---|
62 | The Hypertext Transfer Protocol (HTTP) is an application-level
|
---|
63 | protocol for distributed, collaborative, hypermedia information
|
---|
64 | systems. HTTP has been in use by the World Wide Web global
|
---|
65 | information initiative since 1990. This document is Part 7 of the
|
---|
66 | seven-part specification that defines the protocol referred to as
|
---|
67 | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines
|
---|
68 | HTTP Authentication.
|
---|
69 |
|
---|
70 | Editorial Note (To be removed by RFC Editor)
|
---|
71 |
|
---|
72 | Discussion of this draft should take place on the HTTPBIS working
|
---|
73 | group mailing list (ietf-http-wg@w3.org). The current issues list is
|
---|
74 | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
|
---|
75 | documents (including fancy diffs) can be found at
|
---|
76 | <http://tools.ietf.org/wg/httpbis/>.
|
---|
77 |
|
---|
78 | The changes in this draft are summarized in Appendix B.6.
|
---|
79 |
|
---|
80 |
|
---|
81 |
|
---|
82 |
|
---|
83 |
|
---|
84 |
|
---|
85 |
|
---|
86 |
|
---|
87 |
|
---|
88 |
|
---|
89 |
|
---|
90 |
|
---|
91 |
|
---|
92 |
|
---|
93 |
|
---|
94 |
|
---|
95 |
|
---|
96 |
|
---|
97 |
|
---|
98 |
|
---|
99 |
|
---|
100 |
|
---|
101 |
|
---|
102 |
|
---|
103 |
|
---|
104 |
|
---|
105 |
|
---|
106 |
|
---|
107 |
|
---|
108 |
|
---|
109 |
|
---|
110 |
|
---|
111 | Fielding, et al. Expires May 20, 2009 [Page 2]
|
---|
112 |
|
---|
113 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
114 |
|
---|
115 |
|
---|
116 | Table of Contents
|
---|
117 |
|
---|
118 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
---|
119 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
|
---|
120 | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4
|
---|
121 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
|
---|
122 | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5
|
---|
123 | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5
|
---|
124 | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5
|
---|
125 | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5
|
---|
126 | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6
|
---|
127 | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7
|
---|
128 | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7
|
---|
129 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
|
---|
130 | 5.1. Message Header Registration . . . . . . . . . . . . . . . 8
|
---|
131 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
|
---|
132 | 6.1. Authentication Credentials and Idle Clients . . . . . . . 8
|
---|
133 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
|
---|
134 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
|
---|
135 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
|
---|
136 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
|
---|
137 | Appendix A. Compatibility with Previous Versions . . . . . . . . 10
|
---|
138 | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10
|
---|
139 | Appendix B. Change Log (to be removed by RFC Editor before
|
---|
140 | publication) . . . . . . . . . . . . . . . . . . . . 10
|
---|
141 | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 10
|
---|
142 | B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 10
|
---|
143 | B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 10
|
---|
144 | B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 10
|
---|
145 | B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 10
|
---|
146 | B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 10
|
---|
147 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
---|
148 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
|
---|
149 | Intellectual Property and Copyright Statements . . . . . . . . . . 15
|
---|
150 |
|
---|
151 |
|
---|
152 |
|
---|
153 |
|
---|
154 |
|
---|
155 |
|
---|
156 |
|
---|
157 |
|
---|
158 |
|
---|
159 |
|
---|
160 |
|
---|
161 |
|
---|
162 |
|
---|
163 |
|
---|
164 |
|
---|
165 |
|
---|
166 |
|
---|
167 | Fielding, et al. Expires May 20, 2009 [Page 3]
|
---|
168 |
|
---|
169 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
170 |
|
---|
171 |
|
---|
172 | 1. Introduction
|
---|
173 |
|
---|
174 | This document defines HTTP/1.1 access control and authentication.
|
---|
175 | Right now it includes the extracted relevant sections of RFC 2616
|
---|
176 | with only minor changes. The intention is to move the general
|
---|
177 | framework for HTTP authentication here, as currently specified in
|
---|
178 | [RFC2617], and allow the individual authentication mechanisms to be
|
---|
179 | defined elsewhere. This introduction will be rewritten when that
|
---|
180 | occurs.
|
---|
181 |
|
---|
182 | HTTP provides several OPTIONAL challenge-response authentication
|
---|
183 | mechanisms which can be used by a server to challenge a client
|
---|
184 | request and by a client to provide authentication information. The
|
---|
185 | general framework for access authentication, and the specification of
|
---|
186 | "basic" and "digest" authentication, are specified in "HTTP
|
---|
187 | Authentication: Basic and Digest Access Authentication" [RFC2617].
|
---|
188 | This specification adopts the definitions of "challenge" and
|
---|
189 | "credentials" from that specification.
|
---|
190 |
|
---|
191 | 1.1. Requirements
|
---|
192 |
|
---|
193 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
---|
194 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
---|
195 | document are to be interpreted as described in [RFC2119].
|
---|
196 |
|
---|
197 | An implementation is not compliant if it fails to satisfy one or more
|
---|
198 | of the MUST or REQUIRED level requirements for the protocols it
|
---|
199 | implements. An implementation that satisfies all the MUST or
|
---|
200 | REQUIRED level and all the SHOULD level requirements for its
|
---|
201 | protocols is said to be "unconditionally compliant"; one that
|
---|
202 | satisfies all the MUST level requirements but not all the SHOULD
|
---|
203 | level requirements for its protocols is said to be "conditionally
|
---|
204 | compliant."
|
---|
205 |
|
---|
206 |
|
---|
207 | 2. Notational Conventions and Generic Grammar
|
---|
208 |
|
---|
209 | This specification uses the ABNF syntax defined in Section 2.1 of
|
---|
210 | [Part1].
|
---|
211 |
|
---|
212 | The ABNF rules below are defined in other specifications:
|
---|
213 |
|
---|
214 | OWS = <OWS, defined in [Part1], Section 2.2>
|
---|
215 |
|
---|
216 |
|
---|
217 | challenge = <challenge, defined in [RFC2617], Section 1.2>
|
---|
218 | credentials = <credentials, defined in [RFC2617], Section 1.2>
|
---|
219 |
|
---|
220 |
|
---|
221 |
|
---|
222 |
|
---|
223 | Fielding, et al. Expires May 20, 2009 [Page 4]
|
---|
224 |
|
---|
225 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
226 |
|
---|
227 |
|
---|
228 | 3. Status Code Definitions
|
---|
229 |
|
---|
230 | 3.1. 401 Unauthorized
|
---|
231 |
|
---|
232 | The request requires user authentication. The response MUST include
|
---|
233 | a WWW-Authenticate header field (Section 4.4) containing a challenge
|
---|
234 | applicable to the requested resource. The client MAY repeat the
|
---|
235 | request with a suitable Authorization header field (Section 4.1). If
|
---|
236 | the request already included Authorization credentials, then the 401
|
---|
237 | response indicates that authorization has been refused for those
|
---|
238 | credentials. If the 401 response contains the same challenge as the
|
---|
239 | prior response, and the user agent has already attempted
|
---|
240 | authentication at least once, then the user SHOULD be presented the
|
---|
241 | entity that was given in the response, since that entity might
|
---|
242 | include relevant diagnostic information. HTTP access authentication
|
---|
243 | is explained in "HTTP Authentication: Basic and Digest Access
|
---|
244 | Authentication" [RFC2617].
|
---|
245 |
|
---|
246 | 3.2. 407 Proxy Authentication Required
|
---|
247 |
|
---|
248 | This code is similar to 401 (Unauthorized), but indicates that the
|
---|
249 | client must first authenticate itself with the proxy. The proxy MUST
|
---|
250 | return a Proxy-Authenticate header field (Section 4.2) containing a
|
---|
251 | challenge applicable to the proxy for the requested resource. The
|
---|
252 | client MAY repeat the request with a suitable Proxy-Authorization
|
---|
253 | header field (Section 4.3). HTTP access authentication is explained
|
---|
254 | in "HTTP Authentication: Basic and Digest Access Authentication"
|
---|
255 | [RFC2617].
|
---|
256 |
|
---|
257 |
|
---|
258 | 4. Header Field Definitions
|
---|
259 |
|
---|
260 | This section defines the syntax and semantics of HTTP/1.1 header
|
---|
261 | fields related to authentication.
|
---|
262 |
|
---|
263 | 4.1. Authorization
|
---|
264 |
|
---|
265 | A user agent that wishes to authenticate itself with a server--
|
---|
266 | usually, but not necessarily, after receiving a 401 response--does so
|
---|
267 | by including an Authorization request-header field with the request.
|
---|
268 | The field "Authorization" consists of credentials containing the
|
---|
269 | authentication information of the user agent for the realm of the
|
---|
270 | resource being requested.
|
---|
271 |
|
---|
272 | Authorization = "Authorization" ":" OWS Authorization-v
|
---|
273 | Authorization-v = credentials
|
---|
274 |
|
---|
275 | HTTP access authentication is described in "HTTP Authentication:
|
---|
276 |
|
---|
277 |
|
---|
278 |
|
---|
279 | Fielding, et al. Expires May 20, 2009 [Page 5]
|
---|
280 |
|
---|
281 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
282 |
|
---|
283 |
|
---|
284 | Basic and Digest Access Authentication" [RFC2617]. If a request is
|
---|
285 | authenticated and a realm specified, the same credentials SHOULD be
|
---|
286 | valid for all other requests within this realm (assuming that the
|
---|
287 | authentication scheme itself does not require otherwise, such as
|
---|
288 | credentials that vary according to a challenge value or using
|
---|
289 | synchronized clocks).
|
---|
290 |
|
---|
291 | When a shared cache (see Section 9 of [Part6]) receives a request
|
---|
292 | containing an Authorization field, it MUST NOT return the
|
---|
293 | corresponding response as a reply to any other request, unless one of
|
---|
294 | the following specific exceptions holds:
|
---|
295 |
|
---|
296 | 1. If the response includes the "s-maxage" cache-control directive,
|
---|
297 | the cache MAY use that response in replying to a subsequent
|
---|
298 | request. But (if the specified maximum age has passed) a proxy
|
---|
299 | cache MUST first revalidate it with the origin server, using the
|
---|
300 | request-headers from the new request to allow the origin server
|
---|
301 | to authenticate the new request. (This is the defined behavior
|
---|
302 | for s-maxage.) If the response includes "s-maxage=0", the proxy
|
---|
303 | MUST always revalidate it before re-using it.
|
---|
304 |
|
---|
305 | 2. If the response includes the "must-revalidate" cache-control
|
---|
306 | directive, the cache MAY use that response in replying to a
|
---|
307 | subsequent request. But if the response is stale, all caches
|
---|
308 | MUST first revalidate it with the origin server, using the
|
---|
309 | request-headers from the new request to allow the origin server
|
---|
310 | to authenticate the new request.
|
---|
311 |
|
---|
312 | 3. If the response includes the "public" cache-control directive, it
|
---|
313 | MAY be returned in reply to any subsequent request.
|
---|
314 |
|
---|
315 | 4.2. Proxy-Authenticate
|
---|
316 |
|
---|
317 | The response-header field "Proxy-Authenticate" MUST be included as
|
---|
318 | part of a 407 (Proxy Authentication Required) response. The field
|
---|
319 | value consists of a challenge that indicates the authentication
|
---|
320 | scheme and parameters applicable to the proxy for this Request-URI.
|
---|
321 |
|
---|
322 | Proxy-Authenticate = "Proxy-Authenticate" ":" OWS
|
---|
323 | Proxy-Authenticate-v
|
---|
324 | Proxy-Authenticate-v = 1#challenge
|
---|
325 |
|
---|
326 | The HTTP access authentication process is described in "HTTP
|
---|
327 | Authentication: Basic and Digest Access Authentication" [RFC2617].
|
---|
328 | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
|
---|
329 | only to the current connection and SHOULD NOT be passed on to
|
---|
330 | downstream clients. However, an intermediate proxy might need to
|
---|
331 | obtain its own credentials by requesting them from the downstream
|
---|
332 |
|
---|
333 |
|
---|
334 |
|
---|
335 | Fielding, et al. Expires May 20, 2009 [Page 6]
|
---|
336 |
|
---|
337 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
338 |
|
---|
339 |
|
---|
340 | client, which in some circumstances will appear as if the proxy is
|
---|
341 | forwarding the Proxy-Authenticate header field.
|
---|
342 |
|
---|
343 | 4.3. Proxy-Authorization
|
---|
344 |
|
---|
345 | The request-header field "Proxy-Authorization" allows the client to
|
---|
346 | identify itself (or its user) to a proxy which requires
|
---|
347 | authentication. The Proxy-Authorization field value consists of
|
---|
348 | credentials containing the authentication information of the user
|
---|
349 | agent for the proxy and/or realm of the resource being requested.
|
---|
350 |
|
---|
351 | Proxy-Authorization = "Proxy-Authorization" ":" OWS
|
---|
352 | Proxy-Authorization-v
|
---|
353 | Proxy-Authorization-v = credentials
|
---|
354 |
|
---|
355 | The HTTP access authentication process is described in "HTTP
|
---|
356 | Authentication: Basic and Digest Access Authentication" [RFC2617].
|
---|
357 | Unlike Authorization, the Proxy-Authorization header field applies
|
---|
358 | only to the next outbound proxy that demanded authentication using
|
---|
359 | the Proxy-Authenticate field. When multiple proxies are used in a
|
---|
360 | chain, the Proxy-Authorization header field is consumed by the first
|
---|
361 | outbound proxy that was expecting to receive credentials. A proxy
|
---|
362 | MAY relay the credentials from the client request to the next proxy
|
---|
363 | if that is the mechanism by which the proxies cooperatively
|
---|
364 | authenticate a given request.
|
---|
365 |
|
---|
366 | 4.4. WWW-Authenticate
|
---|
367 |
|
---|
368 | The WWW-Authenticate response-header field MUST be included in 401
|
---|
369 | (Unauthorized) response messages. The field value consists of at
|
---|
370 | least one challenge that indicates the authentication scheme(s) and
|
---|
371 | parameters applicable to the Request-URI.
|
---|
372 |
|
---|
373 | WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
|
---|
374 | WWW-Authenticate-v = 1#challenge
|
---|
375 |
|
---|
376 | The HTTP access authentication process is described in "HTTP
|
---|
377 | Authentication: Basic and Digest Access Authentication" [RFC2617].
|
---|
378 | User agents are advised to take special care in parsing the WWW-
|
---|
379 | Authenticate field value as it might contain more than one challenge,
|
---|
380 | or if more than one WWW-Authenticate header field is provided, the
|
---|
381 | contents of a challenge itself can contain a comma-separated list of
|
---|
382 | authentication parameters.
|
---|
383 |
|
---|
384 |
|
---|
385 | 5. IANA Considerations
|
---|
386 |
|
---|
387 |
|
---|
388 |
|
---|
389 |
|
---|
390 |
|
---|
391 | Fielding, et al. Expires May 20, 2009 [Page 7]
|
---|
392 |
|
---|
393 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
394 |
|
---|
395 |
|
---|
396 | 5.1. Message Header Registration
|
---|
397 |
|
---|
398 | The Message Header Registry located at <http://www.iana.org/
|
---|
399 | assignments/message-headers/message-header-index.html> should be
|
---|
400 | updated with the permanent registrations below (see [RFC3864]):
|
---|
401 |
|
---|
402 | +---------------------+----------+----------+-------------+
|
---|
403 | | Header Field Name | Protocol | Status | Reference |
|
---|
404 | +---------------------+----------+----------+-------------+
|
---|
405 | | Authorization | http | standard | Section 4.1 |
|
---|
406 | | Proxy-Authenticate | http | standard | Section 4.2 |
|
---|
407 | | Proxy-Authorization | http | standard | Section 4.3 |
|
---|
408 | | WWW-Authenticate | http | standard | Section 4.4 |
|
---|
409 | +---------------------+----------+----------+-------------+
|
---|
410 |
|
---|
411 | The change controller is: "IETF (iesg@ietf.org) - Internet
|
---|
412 | Engineering Task Force".
|
---|
413 |
|
---|
414 |
|
---|
415 | 6. Security Considerations
|
---|
416 |
|
---|
417 | This section is meant to inform application developers, information
|
---|
418 | providers, and users of the security limitations in HTTP/1.1 as
|
---|
419 | described by this document. The discussion does not include
|
---|
420 | definitive solutions to the problems revealed, though it does make
|
---|
421 | some suggestions for reducing security risks.
|
---|
422 |
|
---|
423 | 6.1. Authentication Credentials and Idle Clients
|
---|
424 |
|
---|
425 | Existing HTTP clients and user agents typically retain authentication
|
---|
426 | information indefinitely. HTTP/1.1 does not provide a method for a
|
---|
427 | server to direct clients to discard these cached credentials. This
|
---|
428 | is a significant defect that requires further extensions to HTTP.
|
---|
429 | Circumstances under which credential caching can interfere with the
|
---|
430 | application's security model include but are not limited to:
|
---|
431 |
|
---|
432 | o Clients which have been idle for an extended period following
|
---|
433 | which the server might wish to cause the client to reprompt the
|
---|
434 | user for credentials.
|
---|
435 |
|
---|
436 | o Applications which include a session termination indication (such
|
---|
437 | as a `logout' or `commit' button on a page) after which the server
|
---|
438 | side of the application `knows' that there is no further reason
|
---|
439 | for the client to retain the credentials.
|
---|
440 |
|
---|
441 | This is currently under separate study. There are a number of work-
|
---|
442 | arounds to parts of this problem, and we encourage the use of
|
---|
443 | password protection in screen savers, idle time-outs, and other
|
---|
444 |
|
---|
445 |
|
---|
446 |
|
---|
447 | Fielding, et al. Expires May 20, 2009 [Page 8]
|
---|
448 |
|
---|
449 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
450 |
|
---|
451 |
|
---|
452 | methods which mitigate the security problems inherent in this
|
---|
453 | problem. In particular, user agents which cache credentials are
|
---|
454 | encouraged to provide a readily accessible mechanism for discarding
|
---|
455 | cached credentials under user control.
|
---|
456 |
|
---|
457 |
|
---|
458 | 7. Acknowledgments
|
---|
459 |
|
---|
460 | [[anchor2: TBD.]]
|
---|
461 |
|
---|
462 |
|
---|
463 | 8. References
|
---|
464 |
|
---|
465 | 8.1. Normative References
|
---|
466 |
|
---|
467 | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
---|
468 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
|
---|
469 | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
|
---|
470 | and Message Parsing", draft-ietf-httpbis-p1-messaging-05
|
---|
471 | (work in progress), November 2008.
|
---|
472 |
|
---|
473 | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
---|
474 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
|
---|
475 | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
|
---|
476 | draft-ietf-httpbis-p6-cache-05 (work in progress),
|
---|
477 | November 2008.
|
---|
478 |
|
---|
479 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
---|
480 | Requirement Levels", BCP 14, RFC 2119, March 1997.
|
---|
481 |
|
---|
482 | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
|
---|
483 | Leach, P., Luotonen, A., and L. Stewart, "HTTP
|
---|
484 | Authentication: Basic and Digest Access Authentication",
|
---|
485 | RFC 2617, June 1999.
|
---|
486 |
|
---|
487 | 8.2. Informative References
|
---|
488 |
|
---|
489 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
---|
490 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
---|
491 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
---|
492 |
|
---|
493 | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
|
---|
494 | Procedures for Message Header Fields", BCP 90, RFC 3864,
|
---|
495 | September 2004.
|
---|
496 |
|
---|
497 |
|
---|
498 |
|
---|
499 |
|
---|
500 |
|
---|
501 |
|
---|
502 |
|
---|
503 | Fielding, et al. Expires May 20, 2009 [Page 9]
|
---|
504 |
|
---|
505 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
506 |
|
---|
507 |
|
---|
508 | Appendix A. Compatibility with Previous Versions
|
---|
509 |
|
---|
510 | A.1. Changes from RFC 2616
|
---|
511 |
|
---|
512 |
|
---|
513 | Appendix B. Change Log (to be removed by RFC Editor before publication)
|
---|
514 |
|
---|
515 | B.1. Since RFC2616
|
---|
516 |
|
---|
517 | Extracted relevant partitions from [RFC2616].
|
---|
518 |
|
---|
519 | B.2. Since draft-ietf-httpbis-p7-auth-00
|
---|
520 |
|
---|
521 | Closed issues:
|
---|
522 |
|
---|
523 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
|
---|
524 | Informative references"
|
---|
525 |
|
---|
526 | B.3. Since draft-ietf-httpbis-p7-auth-01
|
---|
527 |
|
---|
528 | Ongoing work on ABNF conversion
|
---|
529 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
---|
530 |
|
---|
531 | o Explicitly import BNF rules for "challenge" and "credentials" from
|
---|
532 | RFC2617.
|
---|
533 |
|
---|
534 | o Add explicit references to BNF syntax and rules imported from
|
---|
535 | other parts of the specification.
|
---|
536 |
|
---|
537 | B.4. Since draft-ietf-httpbis-p7-auth-02
|
---|
538 |
|
---|
539 | Ongoing work on IANA Message Header Registration
|
---|
540 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
|
---|
541 |
|
---|
542 | o Reference RFC 3984, and update header registrations for headers
|
---|
543 | defined in this document.
|
---|
544 |
|
---|
545 | B.5. Since draft-ietf-httpbis-p7-auth-03
|
---|
546 |
|
---|
547 | B.6. Since draft-ietf-httpbis-p7-auth-04
|
---|
548 |
|
---|
549 | Ongoing work on ABNF conversion
|
---|
550 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
---|
551 |
|
---|
552 | o Use "/" instead of "|" for alternatives.
|
---|
553 |
|
---|
554 | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
|
---|
555 | whitespace ("OWS") and required whitespace ("RWS").
|
---|
556 |
|
---|
557 |
|
---|
558 |
|
---|
559 | Fielding, et al. Expires May 20, 2009 [Page 10]
|
---|
560 |
|
---|
561 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
562 |
|
---|
563 |
|
---|
564 | o Rewrite ABNFs to spell out whitespace rules, factor out header
|
---|
565 | value format definitions.
|
---|
566 |
|
---|
567 |
|
---|
568 | Index
|
---|
569 |
|
---|
570 | 4
|
---|
571 | 401 Unauthorized (status code) 5
|
---|
572 | 407 Proxy Authentication Required (status code) 5
|
---|
573 |
|
---|
574 | A
|
---|
575 | Authorization header 5
|
---|
576 |
|
---|
577 | G
|
---|
578 | Grammar
|
---|
579 | Authorization 5
|
---|
580 | Authorization-v 5
|
---|
581 | challenge 4
|
---|
582 | credentials 4
|
---|
583 | Proxy-Authenticate 6
|
---|
584 | Proxy-Authenticate-v 6
|
---|
585 | Proxy-Authorization 7
|
---|
586 | Proxy-Authorization-v 7
|
---|
587 | WWW-Authenticate 7
|
---|
588 | WWW-Authenticate-v 7
|
---|
589 |
|
---|
590 | H
|
---|
591 | Headers
|
---|
592 | Authorization 5
|
---|
593 | Proxy-Authenticate 6
|
---|
594 | Proxy-Authorization 7
|
---|
595 | WWW-Authenticate 7
|
---|
596 |
|
---|
597 | P
|
---|
598 | Proxy-Authenticate header 6
|
---|
599 | Proxy-Authorization header 7
|
---|
600 |
|
---|
601 | S
|
---|
602 | Status Codes
|
---|
603 | 401 Unauthorized 5
|
---|
604 | 407 Proxy Authentication Required 5
|
---|
605 |
|
---|
606 | W
|
---|
607 | WWW-Authenticate header 7
|
---|
608 |
|
---|
609 |
|
---|
610 |
|
---|
611 |
|
---|
612 |
|
---|
613 |
|
---|
614 |
|
---|
615 | Fielding, et al. Expires May 20, 2009 [Page 11]
|
---|
616 |
|
---|
617 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
618 |
|
---|
619 |
|
---|
620 | Authors' Addresses
|
---|
621 |
|
---|
622 | Roy T. Fielding (editor)
|
---|
623 | Day Software
|
---|
624 | 23 Corporate Plaza DR, Suite 280
|
---|
625 | Newport Beach, CA 92660
|
---|
626 | USA
|
---|
627 |
|
---|
628 | Phone: +1-949-706-5300
|
---|
629 | Fax: +1-949-706-5305
|
---|
630 | Email: fielding@gbiv.com
|
---|
631 | URI: http://roy.gbiv.com/
|
---|
632 |
|
---|
633 |
|
---|
634 | Jim Gettys
|
---|
635 | One Laptop per Child
|
---|
636 | 21 Oak Knoll Road
|
---|
637 | Carlisle, MA 01741
|
---|
638 | USA
|
---|
639 |
|
---|
640 | Email: jg@laptop.org
|
---|
641 | URI: http://www.laptop.org/
|
---|
642 |
|
---|
643 |
|
---|
644 | Jeffrey C. Mogul
|
---|
645 | Hewlett-Packard Company
|
---|
646 | HP Labs, Large Scale Systems Group
|
---|
647 | 1501 Page Mill Road, MS 1177
|
---|
648 | Palo Alto, CA 94304
|
---|
649 | USA
|
---|
650 |
|
---|
651 | Email: JeffMogul@acm.org
|
---|
652 |
|
---|
653 |
|
---|
654 | Henrik Frystyk Nielsen
|
---|
655 | Microsoft Corporation
|
---|
656 | 1 Microsoft Way
|
---|
657 | Redmond, WA 98052
|
---|
658 | USA
|
---|
659 |
|
---|
660 | Email: henrikn@microsoft.com
|
---|
661 |
|
---|
662 |
|
---|
663 |
|
---|
664 |
|
---|
665 |
|
---|
666 |
|
---|
667 |
|
---|
668 |
|
---|
669 |
|
---|
670 |
|
---|
671 | Fielding, et al. Expires May 20, 2009 [Page 12]
|
---|
672 |
|
---|
673 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
674 |
|
---|
675 |
|
---|
676 | Larry Masinter
|
---|
677 | Adobe Systems, Incorporated
|
---|
678 | 345 Park Ave
|
---|
679 | San Jose, CA 95110
|
---|
680 | USA
|
---|
681 |
|
---|
682 | Email: LMM@acm.org
|
---|
683 | URI: http://larry.masinter.net/
|
---|
684 |
|
---|
685 |
|
---|
686 | Paul J. Leach
|
---|
687 | Microsoft Corporation
|
---|
688 | 1 Microsoft Way
|
---|
689 | Redmond, WA 98052
|
---|
690 |
|
---|
691 | Email: paulle@microsoft.com
|
---|
692 |
|
---|
693 |
|
---|
694 | Tim Berners-Lee
|
---|
695 | World Wide Web Consortium
|
---|
696 | MIT Computer Science and Artificial Intelligence Laboratory
|
---|
697 | The Stata Center, Building 32
|
---|
698 | 32 Vassar Street
|
---|
699 | Cambridge, MA 02139
|
---|
700 | USA
|
---|
701 |
|
---|
702 | Email: timbl@w3.org
|
---|
703 | URI: http://www.w3.org/People/Berners-Lee/
|
---|
704 |
|
---|
705 |
|
---|
706 | Yves Lafon (editor)
|
---|
707 | World Wide Web Consortium
|
---|
708 | W3C / ERCIM
|
---|
709 | 2004, rte des Lucioles
|
---|
710 | Sophia-Antipolis, AM 06902
|
---|
711 | France
|
---|
712 |
|
---|
713 | Email: ylafon@w3.org
|
---|
714 | URI: http://www.raubacapeu.net/people/yves/
|
---|
715 |
|
---|
716 |
|
---|
717 |
|
---|
718 |
|
---|
719 |
|
---|
720 |
|
---|
721 |
|
---|
722 |
|
---|
723 |
|
---|
724 |
|
---|
725 |
|
---|
726 |
|
---|
727 | Fielding, et al. Expires May 20, 2009 [Page 13]
|
---|
728 |
|
---|
729 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
730 |
|
---|
731 |
|
---|
732 | Julian F. Reschke (editor)
|
---|
733 | greenbytes GmbH
|
---|
734 | Hafenweg 16
|
---|
735 | Muenster, NW 48155
|
---|
736 | Germany
|
---|
737 |
|
---|
738 | Phone: +49 251 2807760
|
---|
739 | Fax: +49 251 2807761
|
---|
740 | Email: julian.reschke@greenbytes.de
|
---|
741 | URI: http://greenbytes.de/tech/webdav/
|
---|
742 |
|
---|
743 |
|
---|
744 |
|
---|
745 |
|
---|
746 |
|
---|
747 |
|
---|
748 |
|
---|
749 |
|
---|
750 |
|
---|
751 |
|
---|
752 |
|
---|
753 |
|
---|
754 |
|
---|
755 |
|
---|
756 |
|
---|
757 |
|
---|
758 |
|
---|
759 |
|
---|
760 |
|
---|
761 |
|
---|
762 |
|
---|
763 |
|
---|
764 |
|
---|
765 |
|
---|
766 |
|
---|
767 |
|
---|
768 |
|
---|
769 |
|
---|
770 |
|
---|
771 |
|
---|
772 |
|
---|
773 |
|
---|
774 |
|
---|
775 |
|
---|
776 |
|
---|
777 |
|
---|
778 |
|
---|
779 |
|
---|
780 |
|
---|
781 |
|
---|
782 |
|
---|
783 | Fielding, et al. Expires May 20, 2009 [Page 14]
|
---|
784 |
|
---|
785 | Internet-Draft HTTP/1.1, Part 7 November 2008
|
---|
786 |
|
---|
787 |
|
---|
788 | Full Copyright Statement
|
---|
789 |
|
---|
790 | Copyright (C) The IETF Trust (2008).
|
---|
791 |
|
---|
792 | This document is subject to the rights, licenses and restrictions
|
---|
793 | contained in BCP 78, and except as set forth therein, the authors
|
---|
794 | retain all their rights.
|
---|
795 |
|
---|
796 | This document and the information contained herein are provided on an
|
---|
797 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
---|
798 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
---|
799 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
---|
800 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
---|
801 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
---|
802 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
---|
803 |
|
---|
804 |
|
---|
805 | Intellectual Property
|
---|
806 |
|
---|
807 | The IETF takes no position regarding the validity or scope of any
|
---|
808 | Intellectual Property Rights or other rights that might be claimed to
|
---|
809 | pertain to the implementation or use of the technology described in
|
---|
810 | this document or the extent to which any license under such rights
|
---|
811 | might or might not be available; nor does it represent that it has
|
---|
812 | made any independent effort to identify any such rights. Information
|
---|
813 | on the procedures with respect to rights in RFC documents can be
|
---|
814 | found in BCP 78 and BCP 79.
|
---|
815 |
|
---|
816 | Copies of IPR disclosures made to the IETF Secretariat and any
|
---|
817 | assurances of licenses to be made available, or the result of an
|
---|
818 | attempt made to obtain a general license or permission for the use of
|
---|
819 | such proprietary rights by implementers or users of this
|
---|
820 | specification can be obtained from the IETF on-line IPR repository at
|
---|
821 | http://www.ietf.org/ipr.
|
---|
822 |
|
---|
823 | The IETF invites any interested party to bring to its attention any
|
---|
824 | copyrights, patents or patent applications, or other proprietary
|
---|
825 | rights that may cover technology that may be required to implement
|
---|
826 | this standard. Please address the information to the IETF at
|
---|
827 | ietf-ipr@ietf.org.
|
---|
828 |
|
---|
829 |
|
---|
830 |
|
---|
831 |
|
---|
832 |
|
---|
833 |
|
---|
834 |
|
---|
835 |
|
---|
836 |
|
---|
837 |
|
---|
838 |
|
---|
839 | Fielding, et al. Expires May 20, 2009 [Page 15]
|
---|
840 |
|
---|