draft-ietf-httpbis-p7-auth-16.txt | draft-ietf-httpbis-p7-auth-17.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Updates: 2617 (if approved) Alcatel-Lucent | Updates: 2617 (if approved) Alcatel-Lucent | |||
Intended status: Standards Track J. Mogul | Intended status: Standards Track J. Mogul | |||
Expires: February 25, 2012 HP | Expires: May 3, 2012 HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe | Adobe | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
August 24, 2011 | October 31, 2011 | |||
HTTP/1.1, part 7: Authentication | HTTP/1.1, part 7: Authentication | |||
draft-ietf-httpbis-p7-auth-16 | draft-ietf-httpbis-p7-auth-17 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 7 of the | information initiative since 1990. This document is Part 7 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. | "HTTP/1.1" and, taken together, obsoletes RFC 2616. | |||
skipping to change at page 1, line 48 | skipping to change at page 1, line 48 | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org), which is archived at | group mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix C.17. | The changes in this draft are summarized in Appendix C.18. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on February 25, 2012. | This Internet-Draft will expire on May 3, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 52 | skipping to change at page 2, line 52 | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Access Authentication Framework . . . . . . . . . . . . . . . 5 | 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 | |||
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 | 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 | |||
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 | |||
2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 | 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 | |||
2.3.1. Considerations for New Authentication Schemes . . . . 8 | 2.3.1. Considerations for New Authentication Schemes . . . . 8 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 | |||
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 | |||
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 11 | 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 12 | |||
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 | |||
5.3. Header Field Registration . . . . . . . . . . . . . . . . 11 | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6.1. Authentication Credentials and Idle Clients . . . . . . . 12 | 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 | |||
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 15 | publication) . . . . . . . . . . . . . . . . . . . . 16 | |||
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 15 | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 16 | |||
C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 | C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 | |||
C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 16 | C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 16 | |||
C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 16 | C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 16 | |||
C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 16 | C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 16 | |||
C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 16 | C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 16 | |||
C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 16 | C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 17 | |||
C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 17 | C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 17 | |||
C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 17 | C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 17 | |||
C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 17 | C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 17 | |||
C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 17 | C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 17 | |||
C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 17 | C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 17 | |||
C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 17 | C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 17 | |||
C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 18 | C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 18 | |||
C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 18 | C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 18 | |||
C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 18 | C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 18 | |||
C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 18 | C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 18 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 19 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 access control and authentication. It | This document defines HTTP/1.1 access control and authentication. It | |||
includes the relevant parts of RFC 2616 with only minor changes, plus | includes the relevant parts of RFC 2616 with only minor changes, plus | |||
the general framework for HTTP authentication, as previously defined | the general framework for HTTP authentication, as previously defined | |||
in "HTTP Authentication: Basic and Digest Access Authentication" | in "HTTP Authentication: Basic and Digest Access Authentication" | |||
([RFC2617]). | ([RFC2617]). | |||
HTTP provides several OPTIONAL challenge-response authentication | HTTP provides several OPTIONAL challenge-response authentication | |||
mechanisms which can be used by a server to challenge a client | mechanisms which can be used by a server to challenge a client | |||
request and by a client to provide authentication information. The | request and by a client to provide authentication information. The | |||
"basic" and "digest" authentication schemes continue to be specified | "basic" and "digest" authentication schemes continue to be specified | |||
in RFC 2617. | in RFC 2617. | |||
1.1. Requirements | 1.1. Conformance and Error Handling | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
An implementation is not compliant if it fails to satisfy one or more | This document defines conformance criteria for several roles in HTTP | |||
of the "MUST" or "REQUIRED" level requirements for the protocols it | communication, including Senders, Recipients, Clients, Servers, User- | |||
implements. An implementation that satisfies all the "MUST" or | Agents, Origin Servers, Intermediaries, Proxies and Gateways. See | |||
"REQUIRED" level and all the "SHOULD" level requirements for its | Section 2 of [Part1] for definitions of these terms. | |||
protocols is said to be "unconditionally compliant"; one that | ||||
satisfies all the "MUST" level requirements but not all the "SHOULD" | An implementation is considered conformant if it complies with all of | |||
level requirements for its protocols is said to be "conditionally | the requirements associated with its role(s). Note that SHOULD-level | |||
compliant". | requirements are relevant here, unless one of the documented | |||
exceptions is applicable. | ||||
This document also uses ABNF to define valid protocol elements | ||||
(Section 1.2). In addition to the prose requirements placed upon | ||||
them, Senders MUST NOT generate protocol elements that are invalid. | ||||
Unless noted otherwise, Recipients MAY take steps to recover a usable | ||||
protocol element from an invalid construct. However, HTTP does not | ||||
define specific error handling mechanisms, except in cases where it | ||||
has direct impact on security. This is because different uses of the | ||||
protocol require different error handling strategies; for example, a | ||||
Web browser may wish to transparently recover from a response where | ||||
the Location header field doesn't parse according to the ABNF, | ||||
whereby in a systems control protocol using HTTP, this type of error | ||||
recovery could lead to dangerous consequences. | ||||
1.2. Syntax Notation | 1.2. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 1.2 of | This specification uses the ABNF syntax defined in Section 1.2 of | |||
[Part1] (which extends the syntax defined in [RFC5234] with a list | [Part1] (which extends the syntax defined in [RFC5234] with a list | |||
rule). Appendix B shows the collected ABNF, with the list rule | rule). Appendix B shows the collected ABNF, with the list rule | |||
expanded. | expanded. | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
sequence of data), SP (space), VCHAR (any visible USASCII character), | sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
and WSP (whitespace). | character). | |||
1.2.1. Core Rules | 1.2.1. Core Rules | |||
The core rules below are defined in [Part1]: | The core rules below are defined in [Part1]: | |||
BWS = <BWS, defined in [Part1], Section 1.2.2> | BWS = <BWS, defined in [Part1], Section 1.2.2> | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> | |||
token = <token, defined in [Part1], Section 3.2.3> | token = <token, defined in [Part1], Section 3.2.3> | |||
skipping to change at page 8, line 26 | skipping to change at page 8, line 35 | |||
o The authentication parameter "realm" is reserved for defining | o The authentication parameter "realm" is reserved for defining | |||
Protection Spaces as defined in Section 2.2. New schemes MUST NOT | Protection Spaces as defined in Section 2.2. New schemes MUST NOT | |||
use it in a way incompatible with that definition. | use it in a way incompatible with that definition. | |||
o The "b64token" notation was introduced for compatibility with | o The "b64token" notation was introduced for compatibility with | |||
existing authentication schemes and can only be used once per | existing authentication schemes and can only be used once per | |||
challenge/credentials. New schemes thus ought to use the "auth- | challenge/credentials. New schemes thus ought to use the "auth- | |||
param" syntax instead, because otherwise future extensions will be | param" syntax instead, because otherwise future extensions will be | |||
impossible. | impossible. | |||
o The parsing of challenges and credentials is defined by this | ||||
specification, and cannot be modified by new authentication | ||||
schemes. When the auth-param syntax is used, all parameters ought | ||||
to support both token and quoted-string syntax, and syntactical | ||||
constraints ought to be defined on the field value after parsing | ||||
(i.e., quoted-string processing). This is necessary so that | ||||
recipients can use a generic parser that applies to all | ||||
authentication schemes. | ||||
Note: the fact that the value syntax for the "realm" parameter is | ||||
restricted to quoted-string was a bad design choice not to be | ||||
repeated for new parameters. | ||||
o Authentication schemes need to document whether they are usable in | o Authentication schemes need to document whether they are usable in | |||
origin-server authentication (i.e., using WWW-Authenticate), | origin-server authentication (i.e., using WWW-Authenticate), | |||
and/or proxy authentication (i.e., using Proxy-Authenticate). | and/or proxy authentication (i.e., using Proxy-Authenticate). | |||
o The credentials carried in an Authorization header field are | o The credentials carried in an Authorization header field are | |||
specific to the User Agent, and therefore have the same effect on | specific to the User Agent, and therefore have the same effect on | |||
HTTP caches as the "private" Cache-Control response directive, | HTTP caches as the "private" Cache-Control response directive, | |||
within the scope of the request they appear in. | within the scope of the request they appear in. | |||
Therefore, new authentication schemes which choose not to carry | Therefore, new authentication schemes which choose not to carry | |||
skipping to change at page 11, line 23 | skipping to change at page 11, line 42 | |||
credentials (or different credentials) might affect the response. | credentials (or different credentials) might affect the response. | |||
WWW-Authenticate = 1#challenge | WWW-Authenticate = 1#challenge | |||
User agents are advised to take special care in parsing the WWW- | User agents are advised to take special care in parsing the WWW- | |||
Authenticate field value as it might contain more than one challenge, | Authenticate field value as it might contain more than one challenge, | |||
or if more than one WWW-Authenticate header field is provided, the | or if more than one WWW-Authenticate header field is provided, the | |||
contents of a challenge itself can contain a comma-separated list of | contents of a challenge itself can contain a comma-separated list of | |||
authentication parameters. | authentication parameters. | |||
For instance: | ||||
WWW-Authenticate: Newauth realm="apps", type=1, | ||||
title="Login to \"apps\"", Basic realm="simple" | ||||
This header field contains two challenges; one for the "Newauth" | ||||
scheme with a realm value of "apps", and two additional parameters | ||||
"type" and "title", and another one for the "Basic" scheme with a | ||||
realm value of "simple". | ||||
5. IANA Considerations | 5. IANA Considerations | |||
5.1. Authenticaton Scheme Registry | 5.1. Authenticaton Scheme Registry | |||
The registration procedure for HTTP Authentication Schemes is defined | The registration procedure for HTTP Authentication Schemes is defined | |||
by Section 2.3 of this document. | by Section 2.3 of this document. | |||
The HTTP Method Authentication Scheme shall be created at | The HTTP Method Authentication Scheme shall be created at | |||
<http://www.iana.org/assignments/http-authschemes>. | <http://www.iana.org/assignments/http-authschemes>. | |||
skipping to change at page 13, line 14 | skipping to change at page 13, line 40 | |||
7. Acknowledgments | 7. Acknowledgments | |||
This specification takes over the definition of the HTTP | This specification takes over the definition of the HTTP | |||
Authentication Framework, previously defined in RFC 2617. We thank | Authentication Framework, previously defined in RFC 2617. We thank | |||
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. | John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. | |||
Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for | Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for | |||
their work on that specification. See Section 6 of [RFC2617] for | their work on that specification. See Section 6 of [RFC2617] for | |||
further acknowledgements. | further acknowledgements. | |||
See Section 12 of [Part1] for the Acknowledgments related to this | See Section 11 of [Part1] for the Acknowledgments related to this | |||
document revision. | document revision. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-16 | and Message Parsing", draft-ietf-httpbis-p1-messaging-17 | |||
(work in progress), August 2011. | (work in progress), October 2011. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | |||
6: Caching", draft-ietf-httpbis-p6-cache-16 (work in | 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in | |||
progress), August 2011. | progress), October 2011. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
8.2. Informative References | 8.2. Informative References | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
skipping to change at page 18, line 45 | skipping to change at page 19, line 5 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/257>: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/257>: | |||
"Considerations for new authentications schemes" | "Considerations for new authentications schemes" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth- | |||
param ABNF" | param ABNF" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials | o <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials | |||
ABNF missing SP (still using implied LWS?)" | ABNF missing SP (still using implied LWS?)" | |||
C.18. Since draft-ietf-httpbis-p7-auth-16 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document | ||||
HTTP's error-handling philosophy" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/320>: "add advice on | ||||
defining auth scheme parameters" | ||||
Index | Index | |||
4 | 4 | |||
401 Unauthorized (status code) 8 | 401 Unauthorized (status code) 9 | |||
407 Proxy Authentication Required (status code) 9 | 407 Proxy Authentication Required (status code) 9 | |||
A | A | |||
auth-param 5 | auth-param 5 | |||
auth-scheme 5 | auth-scheme 5 | |||
Authorization header field 9 | Authorization header field 9 | |||
B | B | |||
b64token 5 | b64token 5 | |||
C | C | |||
challenge 5 | challenge 6 | |||
credentials 6 | credentials 6 | |||
G | G | |||
Grammar | Grammar | |||
auth-param 5 | auth-param 5 | |||
auth-scheme 5 | auth-scheme 5 | |||
Authorization 9 | Authorization 10 | |||
b64token 5 | b64token 5 | |||
challenge 5 | challenge 6 | |||
credentials 6 | credentials 6 | |||
Proxy-Authenticate 10 | Proxy-Authenticate 10 | |||
Proxy-Authorization 10 | Proxy-Authorization 11 | |||
realm 7 | realm 7 | |||
WWW-Authenticate 11 | WWW-Authenticate 11 | |||
H | H | |||
Header Fields | Header Fields | |||
Authorization 9 | Authorization 9 | |||
Proxy-Authenticate 10 | Proxy-Authenticate 10 | |||
Proxy-Authorization 10 | Proxy-Authorization 11 | |||
WWW-Authenticate 11 | WWW-Authenticate 11 | |||
P | P | |||
Protection Space 7 | Protection Space 7 | |||
Proxy-Authenticate header field 10 | Proxy-Authenticate header field 10 | |||
Proxy-Authorization header field 10 | Proxy-Authorization header field 11 | |||
R | R | |||
Realm 7 | Realm 7 | |||
realm 7 | realm 7 | |||
realm-value 7 | realm-value 7 | |||
S | S | |||
Status Codes | Status Codes | |||
401 Unauthorized 8 | 401 Unauthorized 9 | |||
407 Proxy Authentication Required 9 | 407 Proxy Authentication Required 9 | |||
W | W | |||
WWW-Authenticate header field 11 | WWW-Authenticate header field 11 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
End of changes. 32 change blocks. | ||||
44 lines changed or deleted | 93 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |