draft-ietf-httpbis-p7-auth-23.txt | draft-ietf-httpbis-p7-auth-24.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Reschke, Ed. | Obsoletes: 2616 (if approved) J. Reschke, Ed. | |||
Updates: 2617 (if approved) greenbytes | Updates: 2617 (if approved) greenbytes | |||
Intended status: Standards Track July 15, 2013 | Intended status: Standards Track September 25, 2013 | |||
Expires: January 16, 2014 | Expires: March 29, 2014 | |||
Hypertext Transfer Protocol (HTTP/1.1): Authentication | Hypertext Transfer Protocol (HTTP/1.1): Authentication | |||
draft-ietf-httpbis-p7-auth-23 | draft-ietf-httpbis-p7-auth-24 | |||
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. This document defines the HTTP Authentication framework. | systems. This document defines the HTTP Authentication framework. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft takes place on the HTTPBIS working group | Discussion of this draft takes place on the HTTPBIS working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | 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 D.4. | The changes in this draft are summarized in Appendix D.5. | |||
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 January 16, 2014. | This Internet-Draft will expire on March 29, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
skipping to change at page 3, line 43 | skipping to change at page 3, line 43 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 | |||
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 16 | publication) . . . . . . . . . . . . . . . . . . . . 16 | |||
D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 | D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 | |||
D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 | D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 | |||
D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17 | D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17 | |||
D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17 | D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
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 | includes the relevant parts of RFC 2616 with only minor changes | |||
([RFC2616]), plus the general framework for HTTP authentication, as | ([RFC2616]), plus the general framework for HTTP authentication, as | |||
previously defined in "HTTP Authentication: Basic and Digest Access | previously defined in "HTTP Authentication: Basic and Digest Access | |||
Authentication" ([RFC2617]). | Authentication" ([RFC2617]). | |||
HTTP provides several OPTIONAL challenge-response authentication | HTTP provides several OPTIONAL challenge-response authentication | |||
skipping to change at page 4, line 32 | skipping to change at page 4, line 32 | |||
"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]. | |||
Conformance criteria and considerations regarding error handling are | Conformance criteria and considerations regarding error handling are | |||
defined in Section 2.5 of [Part1]. | defined in Section 2.5 of [Part1]. | |||
1.2. Syntax Notation | 1.2. Syntax Notation | |||
This specification uses the Augmented Backus-Naur Form (ABNF) | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
notation of [RFC5234] with the list rule extension defined in Section | notation of [RFC5234] with the list rule extension defined in Section | |||
1.2 of [Part1]. Appendix B describes rules imported from other | 7 of [Part1]. Appendix B describes rules imported from other | |||
documents. Appendix C shows the collected ABNF with the list rule | documents. Appendix C shows the collected ABNF with the list rule | |||
expanded. | expanded. | |||
2. Access Authentication Framework | 2. Access Authentication Framework | |||
2.1. Challenge and Response | 2.1. Challenge and Response | |||
HTTP provides a simple challenge-response authentication framework | HTTP provides a simple challenge-response authentication framework | |||
that can be used by a server to challenge a client request and by a | that can be used by a server to challenge a client request and by a | |||
client to provide authentication information. It uses a case- | client to provide authentication information. It uses a case- | |||
skipping to change at page 6, line 36 | skipping to change at page 6, line 36 | |||
gain access, ought to respond with the 403 (Forbidden) status code | gain access, ought to respond with the 403 (Forbidden) status code | |||
(Section 6.5.3 of [Part2]). | (Section 6.5.3 of [Part2]). | |||
The HTTP protocol does not restrict applications to this simple | The HTTP protocol does not restrict applications to this simple | |||
challenge-response framework for access authentication. Additional | challenge-response framework for access authentication. Additional | |||
mechanisms MAY be used, such as encryption at the transport level or | mechanisms MAY be used, such as encryption at the transport level or | |||
via message encapsulation, and with additional header fields | via message encapsulation, and with additional header fields | |||
specifying authentication information. However, such additional | specifying authentication information. However, such additional | |||
mechanisms are not defined by this specification. | mechanisms are not defined by this specification. | |||
Proxies MUST forward the WWW-Authenticate and Authorization header | A proxy MUST forward the WWW-Authenticate and Authorization header | |||
fields unmodified and follow the rules found in Section 4.1. | fields unmodified and follow the rules found in Section 4.1. | |||
2.2. Protection Space (Realm) | 2.2. Protection Space (Realm) | |||
The authentication parameter realm is reserved for use by | The authentication parameter realm is reserved for use by | |||
authentication schemes that wish to indicate the scope of protection. | authentication schemes that wish to indicate the scope of protection. | |||
A protection space is defined by the canonical root URI (the scheme | A protection space is defined by the canonical root URI (the scheme | |||
and authority components of the effective request URI; see Section | and authority components of the effective request URI; see Section | |||
5.5 of [Part1]) of the server being accessed, in combination with the | 5.5 of [Part1]) of the server being accessed, in combination with the | |||
realm value if present. These realms allow the protected resources | realm value if present. These realms allow the protected resources | |||
on a server to be partitioned into a set of protection spaces, each | on a server to be partitioned into a set of protection spaces, each | |||
with its own authentication scheme and/or authorization database. | with its own authentication scheme and/or authorization database. | |||
The realm value is a string, generally assigned by the origin server, | The realm value is a string, generally assigned by the origin server, | |||
that can have additional semantics specific to the authentication | which can have additional semantics specific to the authentication | |||
scheme. Note that a response can have multiple challenges with the | scheme. Note that a response can have multiple challenges with the | |||
same auth-scheme but different realms. | same auth-scheme but different realms. | |||
The protection space determines the domain over which credentials can | The protection space determines the domain over which credentials can | |||
be automatically applied. If a prior request has been authorized, | be automatically applied. If a prior request has been authorized, | |||
the same credentials MAY be reused for all other requests within that | the user agent MAY reuse the same credentials for all other requests | |||
protection space for a period of time determined by the | within that protection space for a period of time determined by the | |||
authentication scheme, parameters, and/or user preference. Unless | authentication scheme, parameters, and/or user preference. Unless | |||
specifically allowed by the authentication scheme, a single | specifically allowed by the authentication scheme, a single | |||
protection space cannot extend outside the scope of its server. | protection space cannot extend outside the scope of its server. | |||
For historical reasons, senders MUST only generate the quoted-string | For historical reasons, a sender MUST only generate the quoted-string | |||
syntax. Recipients might have to support both token and quoted- | syntax. Recipients might have to support both token and quoted- | |||
string syntax for maximum interoperability with existing clients that | string syntax for maximum interoperability with existing clients that | |||
have been accepting both notations for a long time. | have been accepting both notations for a long time. | |||
3. Status Code Definitions | 3. Status Code Definitions | |||
3.1. 401 Unauthorized | 3.1. 401 Unauthorized | |||
The 401 (Unauthorized) status code indicates that the request has not | The 401 (Unauthorized) status code indicates that the request has not | |||
been applied because it lacks valid authentication credentials for | been applied because it lacks valid authentication credentials for | |||
skipping to change at page 8, line 10 | skipping to change at page 8, line 10 | |||
4. Header Field Definitions | 4. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to authentication. | fields related to authentication. | |||
4.1. Authorization | 4.1. Authorization | |||
The "Authorization" header field allows a user agent to authenticate | The "Authorization" header field allows a user agent to authenticate | |||
itself with an origin server -- usually, but not necessarily, after | itself with an origin server -- usually, but not necessarily, after | |||
receiving a 401 (Unauthorized) response. Its value consists of | receiving a 401 (Unauthorized) response. Its value consists of | |||
credentials containing information of the user agent for the realm of | credentials containing the authentication information of the user | |||
the resource being requested. | agent for the realm of the resource being requested. | |||
Authorization = credentials | Authorization = credentials | |||
If a request is authenticated and a realm specified, the same | If a request is authenticated and a realm specified, the same | |||
credentials SHOULD be valid for all other requests within this realm | credentials are presumed to be valid for all other requests within | |||
(assuming that the authentication scheme itself does not require | this realm (assuming that the authentication scheme itself does not | |||
otherwise, such as credentials that vary according to a challenge | require otherwise, such as credentials that vary according to a | |||
value or using synchronized clocks). | challenge value or using synchronized clocks). | |||
See Section 3.2 of [Part6] for details of and requirements pertaining | See Section 3.2 of [Part6] for details of and requirements pertaining | |||
to handling of the Authorization field by HTTP caches. | to handling of the Authorization field by HTTP caches. | |||
4.2. Proxy-Authenticate | 4.2. Proxy-Authenticate | |||
The "Proxy-Authenticate" header field consists of at least one | The "Proxy-Authenticate" header field consists of at least one | |||
challenge that indicates the authentication scheme(s) and parameters | challenge that indicates the authentication scheme(s) and parameters | |||
applicable to the proxy for this effective request URI (Section 5.5 | applicable to the proxy for this effective request URI (Section 5.5 | |||
of [Part1]). It MUST be included as part of a 407 (Proxy | of [Part1]). It MUST be included as part of a 407 (Proxy | |||
Authentication Required) response. | Authentication Required) response. | |||
Proxy-Authenticate = 1#challenge | Proxy-Authenticate = 1#challenge | |||
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | |||
only to the current connection, and intermediaries SHOULD NOT forward | only to the next outbound client on the response chain that chose to | |||
it to downstream clients. However, an intermediate proxy might need | direct its request to the responding proxy. If that recipient is | |||
to obtain its own credentials by requesting them from the downstream | also a proxy, it will generally consume the Proxy-Authenticate header | |||
client, which in some circumstances will appear as if the proxy is | field (and generate an appropriate Proxy-Authorization in a | |||
forwarding the Proxy-Authenticate header field. | subsequent request) rather than forward the header field to its own | |||
outbound clients. However, if a recipient proxy needs to obtain its | ||||
own credentials by requesting them from a further outbound client, it | ||||
will generate its own 407 response, which might have the appearance | ||||
of forwarding the Proxy-Authenticate header field if both proxies use | ||||
the same challenge set. | ||||
Note that the parsing considerations for WWW-Authenticate apply to | Note that the parsing considerations for WWW-Authenticate apply to | |||
this header field as well; see Section 4.4 for details. | this header field as well; see Section 4.4 for details. | |||
4.3. Proxy-Authorization | 4.3. Proxy-Authorization | |||
The "Proxy-Authorization" header field allows the client to identify | The "Proxy-Authorization" header field allows the client to identify | |||
itself (or its user) to a proxy that requires authentication. Its | itself (or its user) to a proxy that requires authentication. Its | |||
value consists of credentials containing the authentication | value consists of credentials containing the authentication | |||
information of the client for the proxy and/or realm of the resource | information of the client for the proxy and/or realm of the resource | |||
being requested. | being requested. | |||
Proxy-Authorization = credentials | Proxy-Authorization = credentials | |||
Unlike Authorization, the Proxy-Authorization header field applies | Unlike Authorization, the Proxy-Authorization header field applies | |||
only to the next outbound proxy that demanded authentication using | only to the next inbound proxy that demanded authentication using the | |||
the Proxy-Authenticate field. When multiple proxies are used in a | Proxy-Authenticate field. When multiple proxies are used in a chain, | |||
chain, the Proxy-Authorization header field is consumed by the first | the Proxy-Authorization header field is consumed by the first inbound | |||
outbound proxy that was expecting to receive credentials. A proxy | proxy that was expecting to receive credentials. A proxy MAY relay | |||
MAY relay the credentials from the client request to the next proxy | the credentials from the client request to the next proxy if that is | |||
if that is the mechanism by which the proxies cooperatively | the mechanism by which the proxies cooperatively authenticate a given | |||
authenticate a given request. | request. | |||
4.4. WWW-Authenticate | 4.4. WWW-Authenticate | |||
The "WWW-Authenticate" header field consists of at least one | The "WWW-Authenticate" header field consists of at least one | |||
challenge that indicates the authentication scheme(s) and parameters | challenge that indicates the authentication scheme(s) and parameters | |||
applicable to the effective request URI (Section 5.5 of [Part1]). | applicable to the effective request URI (Section 5.5 of [Part1]). | |||
It MUST be included in 401 (Unauthorized) response messages and MAY | It MUST be included in 401 (Unauthorized) response messages and MAY | |||
be included in other response messages to indicate that supplying | be included in other response messages to indicate that supplying | |||
credentials (or different credentials) might affect the response. | credentials (or different credentials) might affect the response. | |||
skipping to change at page 11, line 30 | skipping to change at page 11, line 33 | |||
defining new parameters (such as "update the specification", or | defining new parameters (such as "update the specification", or | |||
"use this registry"). | "use this registry"). | |||
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 | |||
(Section 7.2.2.6 of [Part6]), within the scope of the request they | (Section 5.2.2.6 of [Part6]), within the scope of the request they | |||
appear in. | appear in. | |||
Therefore, new authentication schemes that choose not to carry | Therefore, new authentication schemes that choose not to carry | |||
credentials in the Authorization header field (e.g., using a newly | credentials in the Authorization header field (e.g., using a newly | |||
defined header field) will need to explicitly disallow caching, by | defined header field) will need to explicitly disallow caching, by | |||
mandating the use of either Cache-Control request directives | mandating the use of either Cache-Control request directives | |||
(e.g., "no-store", Section 7.2.1.5 of [Part6]) or response | (e.g., "no-store", Section 5.2.1.5 of [Part6]) or response | |||
directives (e.g., "private"). | directives (e.g., "private"). | |||
5.2. Status Code Registration | 5.2. Status Code Registration | |||
The HTTP Status Code Registry located at | The HTTP Status Code Registry located at | |||
<http://www.iana.org/assignments/http-status-codes> shall be updated | <http://www.iana.org/assignments/http-status-codes> shall be updated | |||
with the registrations below: | with the registrations below: | |||
+-------+-------------------------------+-------------+ | +-------+-------------------------------+-------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
skipping to change at page 12, line 44 | skipping to change at page 12, line 44 | |||
6. Security Considerations | 6. Security Considerations | |||
This section is meant to inform developers, information providers, | This section is meant to inform developers, information providers, | |||
and users of known security concerns specific to HTTP/1.1 | and users of known security concerns specific to HTTP/1.1 | |||
authentication. More general security considerations are addressed | authentication. More general security considerations are addressed | |||
in HTTP messaging [Part1] and semantics [Part2]. | in HTTP messaging [Part1] and semantics [Part2]. | |||
6.1. Authentication Credentials and Idle Clients | 6.1. Authentication Credentials and Idle Clients | |||
Existing HTTP clients and user agents typically retain authentication | Existing HTTP clients and user agents typically retain authentication | |||
information indefinitely. HTTP/1.1 does not provide a method for a | information indefinitely. HTTP does not provide a mechanism for the | |||
server to direct clients to discard these cached credentials. This | origin server to direct clients to discard these cached credentials, | |||
is a significant defect that requires further extensions to HTTP. | since the protocol has no awareness of how credentials are obtained | |||
or managed by the user agent. The mechanisms for expiring or | ||||
revoking credentials can be specified as part of an authentication | ||||
scheme definition. | ||||
Circumstances under which credential caching can interfere with the | Circumstances under which credential caching can interfere with the | |||
application's security model include but are not limited to: | application's security model include but are not limited to: | |||
o Clients that have been idle for an extended period, following | o Clients that have been idle for an extended period, following | |||
which the server might wish to cause the client to re-prompt the | which the server might wish to cause the client to re-prompt the | |||
user for credentials. | user for credentials. | |||
o Applications that include a session termination indication (such | o Applications that include a session termination indication (such | |||
as a "logout" or "commit" button on a page) after which the server | as a "logout" or "commit" button on a page) after which the server | |||
side of the application "knows" that there is no further reason | side of the application "knows" that there is no further reason | |||
for the client to retain the credentials. | for the client to retain the credentials. | |||
This is currently under separate study. There are a number of work- | User agents that cache credentials are encouraged to provide a | |||
arounds to parts of this problem, and we encourage the use of | readily accessible mechanism for discarding cached credentials under | |||
password protection in screen savers, idle time-outs, and other | user control. | |||
methods that mitigate the security problems inherent in this problem. | ||||
In particular, user agents that cache credentials are encouraged to | ||||
provide a readily accessible mechanism for discarding cached | ||||
credentials under user control. | ||||
6.2. Protection Spaces | 6.2. Protection Spaces | |||
Authentication schemes that solely rely on the "realm" mechanism for | Authentication schemes that solely rely on the "realm" mechanism for | |||
establishing a protection space will expose credentials to all | establishing a protection space will expose credentials to all | |||
resources on an origin server. Clients that have successfully made | resources on an origin server. Clients that have successfully made | |||
authenticated requests with a resource can use the same | authenticated requests with a resource can use the same | |||
authentication credentials for other resources on the same origin | authentication credentials for other resources on the same origin | |||
server. This makes it possible for a different resource to harvest | server. This makes it possible for a different resource to harvest | |||
authentication credentials for other resources. | authentication credentials for other resources. | |||
skipping to change at page 13, line 45 | skipping to change at page 13, line 45 | |||
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 9 of [Part1] for the Acknowledgments related to this | See Section 10 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. and J. Reschke, Ed., "Hypertext Transfer | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
draft-ietf-httpbis-p1-messaging-23 (work in progress), | draft-ietf-httpbis-p1-messaging-24 (work in progress), | |||
July 2013. | September 2013. | |||
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Semantics and Content", | Protocol (HTTP/1.1): Semantics and Content", | |||
draft-ietf-httpbis-p2-semantics-23 (work in progress), | draft-ietf-httpbis-p2-semantics-24 (work in progress), | |||
July 2013. | September 2013. | |||
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
draft-ietf-httpbis-p6-cache-23 (work in progress), | draft-ietf-httpbis-p6-cache-24 (work in progress), | |||
July 2013. | September 2013. | |||
[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 | |||
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
skipping to change at page 17, line 43 | skipping to change at page 17, line 43 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: | |||
mechanism vs framework vs scheme" | mechanism vs framework vs scheme" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial | o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial | |||
suggestions" | suggestions" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of | o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of | |||
extension point considerations" | extension point considerations" | |||
D.5. Since draft-ietf-httpbis-p7-auth-23 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding | ||||
Proxy-*" | ||||
Index | Index | |||
4 | 4 | |||
401 Unauthorized (status code) 7 | 401 Unauthorized (status code) 7 | |||
407 Proxy Authentication Required (status code) 7 | 407 Proxy Authentication Required (status code) 7 | |||
A | A | |||
Authorization header field 8 | Authorization header field 8 | |||
C | C | |||
Canonical Root URI 6 | Canonical Root URI 6 | |||
G | G | |||
Grammar | Grammar | |||
auth-param 5 | auth-param 5 | |||
auth-scheme 5 | auth-scheme 5 | |||
Authorization 8 | Authorization 8 | |||
challenge 5 | challenge 5 | |||
credentials 6 | credentials 6 | |||
Proxy-Authenticate 8 | Proxy-Authenticate 8 | |||
Proxy-Authorization 8 | Proxy-Authorization 9 | |||
token68 5 | token68 5 | |||
WWW-Authenticate 9 | WWW-Authenticate 9 | |||
P | P | |||
Protection Space 6 | Protection Space 6 | |||
Proxy-Authenticate header field 8 | Proxy-Authenticate header field 8 | |||
Proxy-Authorization header field 8 | Proxy-Authorization header field 8 | |||
R | R | |||
Realm 6 | Realm 6 | |||
End of changes. 24 change blocks. | ||||
50 lines changed or deleted | 63 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/ |