RFC 7235

Hypertext Transfer Protocol (HTTP/1.1): Authentication

📅 published June 2014, from ietf

🎀 Internet Engineering Task Force (IETF) ✨

Okay so bestie, this is RFC 7235 💖, titled "Hypertext Transfer Protocol (HTTP/1.1): Authentication" 🦋. It was written by R. Fielding, Ed. (Adobe) and J. Reschke, Ed. (greenbytes) 🫶. It's a Standards Track document, published June 2014 🌸. It obsoletes RFC 2616 and updates RFC 2617 💅, and its ISSN is 2070-1721 🔥.

Request for Comments: 7235 Obsoletes: 2616 Updates: 2617 Category: Standards Track ISSN: 2070-1721

Abstract ⭐

HTTP is a stateless application-level protocol for distributed, collaborative, hypermedia information systems 🌈. This document defines the HTTP Authentication framework 🔐.

Status of This Memo 📜

This is an Internet Standards Track document 💜. It's a product of the IETF and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the IESG 💅. More info on Internet Standards is in Section 2 of RFC 5741 ✨. You can find the current status, errata, and feedback info at http://www.rfc-editor.org/info/rfc7235 🦋.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication 📜. Please review these documents carefully, because they describe your rights and restrictions 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and are provided without warranty as described in the Simplified BSD License 💅.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🌸. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process 😭. Without obtaining an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🧚.

Table of Contents 🌈

1. Introduction ....................................................3
   1.1. Conformance and Error Handling .............................3
   1.2. Syntax Notation ............................................3
2. Access Authentication Framework .................................3
   2.1. Challenge and Response .....................................3
   2.2. Protection Space (Realm) ...................................5
3. Status Code Definitions .........................................6
   3.1. 401 Unauthorized ...........................................6
   3.2. 407 Proxy Authentication Required ..........................6
4. Header Field Definitions ........................................7
   4.1. WWW-Authenticate ...........................................7
   4.2. Authorization ..............................................8
   4.3. Proxy-Authenticate .........................................8
   4.4. Proxy-Authorization ........................................9
5. IANA Considerations .............................................9
   5.1. Authentication Scheme Registry .............................9
        5.1.1. Procedure ...........................................9
        5.1.2. Considerations for New Authentication Schemes ......10
   5.2. Status Code Registration ..................................11
   5.3. Header Field Registration .................................11
6. Security Considerations ........................................12
   6.1. Confidentiality of Credentials ............................12
   6.2. Authentication Credentials and Idle Clients ...............12
   6.3. Protection Spaces .........................................13
7. Acknowledgments ................................................14
8. References .....................................................14
   8.1. Normative References ......................................14
   8.2. Informative References ....................................14
Appendix A. Changes from RFCs 2616 and 2617 .......................16
Appendix B. Imported ABNF .........................................16
Appendix C. Collected ABNF ........................................17
Index .............................................................18

1. Introduction 🦋

Okay so HTTP gives you a general framework for access control and authentication 💅. It's built on an extensible set of challenge-response authentication schemes 🔥. A server can use it to challenge a client's request, and a client can use it to provide its authentication info ✨. This document defines HTTP/1.1 authentication in terms of the architecture from "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" [RFC7230] 💖. It also brings in the general framework from "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617], plus the related fields and status codes from "Hypertext Transfer Protocol -- HTTP/1.1" [RFC2616] 🌸.

The IANA Authentication Scheme Registry (Section 5.1) lists the registered authentication schemes and their specs 🧚. That includes the "basic" and "digest" schemes that RFC 2617 originally defined 🫶.

1.1. Conformance and Error Handling 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

Conformance criteria and error-handling considerations are defined in Section 2.5 of [RFC7230] 💅.

1.2. Syntax Notation 🌈

This spec uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] 🔥, with a list extension from Section 7 of [RFC7230] 🦋. That extension lets you define comma-separated lists compactly using a # operator, kind of like how * means repetition 💖. Appendix B describes the rules imported from other documents 🌸. Appendix C shows the full grammar with all the list operators expanded into standard ABNF 🧚.

2. Access Authentication Framework 🔐

2.1. Challenge and Response 🫶

HTTP has a simple challenge-response authentication framework 💅. A server uses it to challenge a client request, and a client uses it to provide authentication info 🔥. It uses a case-insensitive token to identify the authentication scheme, followed by any extra info that scheme needs ✨. That extra info can be either a comma-separated list of parameters, or a single sequence of characters that can hold base64-encoded data 💖.

Authentication parameters are name=value pairs 🌸. The name token is matched case-insensitively, and each parameter name MUST only occur once per challenge 😭.

  auth-scheme    = token

  auth-param     = token BWS "=" BWS ( token / quoted-string )

  token68        = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="

The token68 syntax allows the 66 unreserved URI characters ([RFC3986]), plus a few others 🦋. That means it can hold base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding 🧚. It excludes whitespace ([RFC4648]) 🙈.

A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent 💜. It includes a WWW-Authenticate header field with at least one challenge that applies to the requested resource 🎀.

A 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client 🌈. It includes a Proxy-Authenticate header field with at least one challenge that applies to the proxy for the requested resource 💅.

  challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note: Many clients fail to parse a challenge that contains an unknown scheme 💀. A workaround for this is to list well-supported schemes (such as "basic") first 🫶.

A user agent that wants to authenticate itself with an origin server 🔥 (usually, but not necessarily, after receiving a 401 (Unauthorized)) can do so by including an Authorization header field with the request ✨.

A client that wants to authenticate itself with a proxy 🌸 (usually, but not necessarily, after receiving a 407 (Proxy Authentication Required)) can do so by including a Proxy-Authorization header field with the request 🧚.

Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the requested resource 💖. Those credentials are based on a challenge received in a response, possibly at some point in the past 🦋. When creating their values, the user agent ought to select the challenge with what it considers the most secure auth-scheme that it understands, and get credentials from the user as appropriate 💅. Sending credentials inside header field values has serious security considerations for the confidentiality of the underlying connection, as described in Section 6.1 😭🔐.

  credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

When an origin server gets a request for a protected resource that omits credentials, has invalid credentials (e.g., a bad password), or has partial credentials (e.g., when the scheme needs more than one round trip), it SHOULD send a 401 (Unauthorized) response 🎀. That response contains a WWW-Authenticate header field with at least one (possibly new) challenge that applies to the requested resource 🌈.

Likewise, when a proxy gets a request that omits proxy credentials or has invalid or partial proxy credentials, a proxy that requires authentication SHOULD generate a 407 (Proxy Authentication Required) response 💜. That response contains a Proxy-Authenticate header field with at least one (possibly new) challenge that applies to the proxy ⭐.

A server that gets valid credentials that aren't good enough to get access ought to respond with the 403 (Forbidden) status code (Section 6.5.3 of [RFC7231]) 🙈.

HTTP doesn't limit applications to this simple challenge-response framework for access authentication 🧚. You can use additional mechanisms, like authentication at the transport level or via message encapsulation, along with extra header fields that carry authentication info 🦋. However, this specification doesn't define those additional mechanisms 💅.

Part 1 of 3. More parts coming, bestie! 🫶💖

2.2. Protection Space (Realm) 🌸

okay so the realm auth parameter is reserved for auth schemes that want to say "this is the scope of protection" 🎀 it's basically a label for a chunk of a server's stuff

a protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI; see Section 5.5 of [RFC7230]) of the server being accessed, combined with the realm value if there is one ✨ realms let a server split its protected resources into multiple protection spaces, and each one can have its own auth scheme and/or authorization database 💅 the realm value is a string, usually assigned by the origin server, and it can carry extra meaning specific to the auth scheme 🦋 also, a single response can have multiple challenges with the same auth-scheme but different realms, which is very main character of it 👑

the protection space decides where credentials can be automatically applied 🫶 if a previous request got authorized, the user agent MAY reuse those same credentials for all the other requests in that protection space for a while. how long depends on the auth scheme, its parameters, and/or user preferences (like a configurable inactivity timeout) ⏳ and unless the auth scheme specifically allows it, a single protection space cannot extend outside the scope of its server 🚫

for historical reasons, a sender MUST only generate the quoted-string syntax 🎀 recipients might still have to support both token and quoted-string syntax, because lots of existing clients have been accepting both for ages and we need to stay interoperable 🫠

3. Status Code Definitions ✨

3.1. 401 Unauthorized 🔐

the 401 (Unauthorized) status code means the request was NOT applied, because it doesn't have valid authentication credentials for the target resource 😭 the server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge that applies to the target resource.

if the request DID include credentials, then a 401 response means authorization was refused for those credentials 💀 the user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). if the 401 response has the same challenge as the prior response, AND the user agent already tried authenticating at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually has relevant diagnostic info 🧚

3.2. 407 Proxy Authentication Required 🍓

the 407 (Proxy Authentication Required) status code is kinda like 401 (Unauthorized), but this one means the client needs to authenticate itself in order to use a proxy 🙈 the proxy MUST send a Proxy-Authenticate header field (Section 4.3) containing a challenge that applies to that proxy for the target resource. the client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 4.4).

4. Header Field Definitions 💜

this section defines the syntax and semantics of header fields related to the HTTP authentication framework 🦋

4.1. WWW-Authenticate 🌈

the "WWW-Authenticate" header field tells you the auth scheme(s) and parameters that apply to the target resource 💖

WWW-Authenticate = 1#challenge

a server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge 🫶 a server MAY generate a WWW-Authenticate header field in other response messages too, to signal that supplying credentials (or different credentials) might change the response.

a proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response 🚫

user agents should be extra careful when parsing this field value 👀 it might contain more than one challenge, each challenge can have a comma-separated list of auth parameters, and the header field itself can show up multiple times. it's a whole thing 😭

for example:

WWW-Authenticate: Newauth realm="apps", type=1,
                  title="Login to \"apps\"", Basic realm="simple"

this header field has two challenges 💅 one is for the "Newauth" scheme with a realm value of "apps", plus two extra parameters, "type" and "title". the other one is for the "Basic" scheme with a realm value of "simple" ✨

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value and thus is harmless. 🙈

4.2. Authorization 🔑

the "Authorization" header field lets a user agent authenticate itself with an origin server 🎀 usually this happens after getting a 401 (Unauthorized) response, but not always 🤷‍♀️ its value holds credentials with the user agent's auth info for the realm of the resource being requested.

Authorization = credentials

if a request is authenticated and a realm is specified, the same credentials are presumed valid for all other requests within this realm 💜 this is assuming the auth scheme itself doesn't require otherwise, like credentials that change based on a challenge value or that rely on synchronized clocks ⏰

a proxy forwarding a request MUST NOT modify any Authorization fields in that request 🚫 for details and requirements on how HTTP caches handle the Authorization field, see Section 3.2 of [RFC7234].

4.3. Proxy-Authenticate 🦋

the "Proxy-Authenticate" header field has at least one challenge that tells you the auth scheme(s) and parameters that apply to the proxy for this effective request URI (Section 5.5 of [RFC7230]) ✨ a proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response it generates.

Proxy-Authenticate = 1#challenge

unlike WWW-Authenticate, the Proxy-Authenticate header field only applies to the next outbound client on the response chain 🔗 this makes sense, because only the client that picked a given proxy is likely to have the credentials needed to authenticate. BUT when multiple proxies live in the same administrative domain (like office and regional caching proxies in a big corporate network), it's common for the credentials to be generated by the user agent and passed along the hierarchy until someone uses them 🏢 so in that kind of setup, it'll look like Proxy-Authenticate is being forwarded, because each proxy sends the same challenge set 🫠

the parsing considerations for WWW-Authenticate also apply to this header field; see Section 4.1 for details 🧠

4.4. Proxy-Authorization 🗝️

the "Proxy-Authorization" header field lets the client identify itself (or its user) to a proxy that needs authentication 💖 its value holds credentials with the client's auth info for the proxy and/or the realm of the resource being requested.

Proxy-Authorization = credentials

unlike Authorization, the Proxy-Authorization header field only applies to the next inbound proxy that demanded authentication using the Proxy-Authenticate field 🎯 when multiple proxies are chained, the first inbound proxy that was expecting credentials is the one that consumes the Proxy-Authorization header field 🍓 a proxy MAY relay the credentials from the client request to the next proxy, if that's how the proxies work together to authenticate a request 🤝

5. IANA Considerations 📋

5.1. Authentication Scheme Registry 🗂️

the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the auth schemes used in challenges and credentials ✨ it has been created and is maintained at http://www.iana.org/assignments/http-authschemes.

5.1.1. Procedure 📝

registrations MUST include the following fields:

  • Authentication Scheme Name
  • Pointer to specification text
  • Notes (optional)

values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1) 🌷

5.1.2. Considerations for New Authentication Schemes 💡

there are some aspects of the HTTP Authentication Framework that put constraints on how new auth schemes can work 🧩

  • HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than depending on the server remembering prior requests. authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure the connection can't be used by anyone other than the authenticated user (see Section 2.3 of [RFC7230]) 🚨
  • the authentication parameter "realm" is reserved for defining protection spaces as described in Section 2.2. new schemes MUST NOT use it in a way that's incompatible with that definition 🚫
  • the "token68" notation was introduced for compatibility with existing auth schemes, and it can only be used once per challenge or credential. so new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible 😭
  • the parsing of challenges and credentials is defined by this specification and cannot be modified by new auth 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 auth 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. 💀
  • definitions of new schemes ought to define the treatment of unknown extension parameters. in general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients 🫶 it's also good to describe the policy for defining new parameters (such as "update the specification" or "use this registry") 📜
  • auth schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/or proxy authentication (i.e., using Proxy-Authenticate) 🏷️
  • the credentials carried in an Authorization header field are specific to the user agent, so they have the same effect on HTTP caches as the "private" Cache-Control response directive (Section 5.2.2.6 of [RFC7234]), within the scope of the request in which they appear 🔒

therefore, new auth schemes that choose NOT to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private") 🙅‍♀️✨

5.2. Status Code Registration ✨

okay so the "Hypertext Transfer Protocol (HTTP) Status Code Registry" over at <http://www.iana.org/assignments/http-status-codes> just got two new entries, bestie 🎀 here they are:

+-------+-------------------------------+-------------+
| Value | Description                   | Reference   |
+-------+-------------------------------+-------------+
| 401   | Unauthorized                  | Section 3.1 |
| 407   | Proxy Authentication Required | Section 3.2 |
+-------+-------------------------------+-------------+

5.3. Header Field Registration 🦋

HTTP header fields live in the "Message Headers" registry, which is maintained at <http://www.iana.org/assignments/message-headers/> 📚

This doc defines the following header fields, so the "Permanent Message Header Field Names" registry got updated to match (see [BCP90]) ✨

+---------------------+----------+----------+-------------+
| Header Field Name   | Protocol | Status   | Reference   |
+---------------------+----------+----------+-------------+
| Authorization       | http     | standard | Section 4.2 |
| Proxy-Authenticate  | http     | standard | Section 4.3 |
| Proxy-Authorization | http     | standard | Section 4.4 |
| WWW-Authenticate    | http     | standard | Section 4.1 |
+---------------------+----------+----------+-------------+

The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 👑

6. Security Considerations 🔥

this section is here to spill the tea on the security stuff devs, info providers, and users need to know about HTTP auth 💅 the general security stuff lives in HTTP messaging [RFC7230] and semantics [RFC7231], so go read those too.

ngl, this list is NOT exhaustive. like, everything about HTTP auth is a security consideration 💀 it's also only about the framework in general, not every single scheme's quirks. those belong in each scheme's own spec. if you want current research and common pitfalls for auth schemes people actually use, [OWASP] has you covered 🌈

6.1. Confidentiality of Credentials 🔐

the HTTP auth framework doesn't have ONE mechanism for keeping credentials confidential. instead, each scheme decides how its credentials get encoded before they're sent. that's flexible for future schemes, but it's not enough for existing schemes that give zero confidentiality on their own, or that don't protect well against replay attacks 😭 also, if the server wants credentials unique to each person, sending them identifies that person even when the credential contents stay secret.

HTTP leans on the transport- or session-level connection for confidential header fields. so if a server gates access with this framework, it needs to make sure the connection is secured in a way that fits the scheme being used 🫶 for example, services that rely on individual user auth often need a TLS ("Transport Layer Security", [RFC5246]) connection set up before any credentials get exchanged 🔒

6.2. Authentication Credentials and Idle Clients 🫠

real talk, existing HTTP clients and user agents usually hang onto auth info forever 😩 HTTP has no way for the origin server to tell clients to toss cached credentials, since the protocol doesn't know how the user agent gets or manages them. expiring or revoking creds can be spelled out in a scheme's definition instead 🙈

caching creds can mess with the app's security model in a few situations, including (but not limited to):

  • clients that have been idle for a long time, after which the server might want to make the client re-prompt the user for credentials.
  • apps with a session termination thing (like a "logout" or "commit" button on a page). after that, the server side "knows" there's no reason for the client to keep the credentials.

user agents that cache creds are encouraged to offer an easy-to-reach way to discard them under user control 🧹✨

6.3. Protection Spaces 👀

schemes that only use the "realm" mechanism to set up a protection space will expose credentials to ALL resources on an origin server. ugh. once a client has successfully made an authenticated request to one resource, it can reuse those same credentials for other resources on that same origin server. so a different resource could harvest credentials meant for others 😱

this is especially worrying when an origin server hosts resources for multiple parties under the same canonical root URI (Section 2.2). possible fixes include restricting direct access to the credentials (i.e., not making the content of the Authorization request header field available), and separating protection spaces by giving each party its own host name (or port number) 💜

7. Acknowledgments 🫶

this spec takes over the HTTP Authentication Framework that used to live in RFC 2617 🌸 huge thank yous to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that one. more acknowledgments are in Section 6 of [RFC2617].

for the acknowledgments tied to this revision, check Section 10 of [RFC7230] 💖

8. References 📚

8.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
  • [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

8.2. Informative References

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
  • [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web Applications and Web Services", The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Appendix A. Changes from RFCs 2616 and 2617 🦋

the HTTP Authentication framework is now defined by this document instead of RFC 2617, so update your bookmarks 🔖

the "realm" parameter isn't always required on challenges anymore, so the ABNF now allows challenges with no auth parameters at all. (Section 2) 🌷

the "token68" alternative to auth-param lists got added for consistency with legacy schemes like "Basic". (Section 2) 🧁

this spec also introduces the Authentication Scheme Registry, along with considerations for new auth schemes. (Section 5.1) 👑

Appendix B. Imported ABNF 🧚

the core rules below are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (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 sequence of data), SP (space), and VCHAR (any visible US-ASCII character).

these rules are defined in [RFC7230]:

  BWS           = <BWS, see [RFC7230], Section 3.2.3>
  OWS           = <OWS, see [RFC7230], Section 3.2.3>
  quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
  token         = <token, see [RFC7230], Section 3.2.6>

Appendix C. Collected ABNF 🍓

in the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230] 💜

Authorization = credentials

BWS = <BWS, see [RFC7230], Section 3.2.3>

OWS = <OWS, see [RFC7230], Section 3.2.3>

Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
 challenge ] )
Proxy-Authorization = credentials

WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
 ] )

auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token

challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
 OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
 *( OWS "," [ OWS auth-param ] ) ] ) ]

quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>

token = <token, see [RFC7230], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
 *"="

Index 📇

4
   401 Unauthorized (status code)  6
   407 Proxy Authentication Required (status code)  6

A
   Authorization header field  8

C
   Canonical Root URI  5

G
   Grammar
      auth-param  4
      auth-scheme  4
      Authorization  8
      challenge  4
      credentials  5
      Proxy-Authenticate  8
      Proxy-Authorization  9
      token68  4
      WWW-Authenticate  7

P
   Protection Space  5
   Proxy-Authenticate header field  8
   Proxy-Authorization header field  9

R
   Realm  5

W
   WWW-Authenticate header field  7

Authors' Addresses 💌

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA  95110
USA

EMail: fielding@gbiv.com
URI:   http://roy.gbiv.com/


Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW  48155
Germany

EMail: julian.reschke@greenbytes.de
URI:   http://greenbytes.de/tech/webdav/
📦 where this page comes from