Subject: Syntax for WWW-Authenticate

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 08 Dec 1999 09:13:06 -0500

The Authorization and WWW-Authenticate headers have truly awful syntax
(*), since they allow the use of commas for both parameter and header
separation. The following is legal to declare one's ability to support
both basic and digest authentication:

WWW-Authenticate: basic realm=br, digest realm=dr, nonce=hex,
                  more=parameter

Note that the only way to tell that a new header has begun is to either
recognize "digest" (dangerous, since new mechanisms could be invented)
or to see that two words are separated by white space, rather than
comma. This means that the parser has to look ahead to decide what to do
and can't split headers.

My suggestion would be to strongly discourage this syntax and only use
the equivalent

WWW-Authenticate: basic realm=br, par=value, par=value
WWW-Authenticate: digest realm=dr, ...

instead. The pain of supporting the single-header form just doesn't seem
worth it.

Henning

(*) which we inherited from HTTP, just to place blame properly :-)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Dec 1999 10:00:08 -0500

> instead. The pain of supporting the single-header form just doesn't seem

My concerns are about having special cases; every other header can
appear in both forms, but not this one. This may cause problems for
existing parsers which assume they can always convert between the two. I
guess the best thing is to make this an open call for comment: Does
anyone have a parser/implementation for which mandating separate headers
is going to break things?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 08 Dec 1999 09:59:48 -0500

> appear in both forms, but not this one. This may cause problems for

I agree, except that this header already breaks the standard HTTP syntax
rules (which would mandate the use of semicolons to avoids this
problem), so this header gets no sympathy from me :-)

> is going to break things?

Note that this only affects the generation of headers, not the parsing.
Indeed, the two-header version is already suggested as the canonical
form in any event.

The inverse question would be which parsers actually correctly *handle*
the merged form...