Subject: Clarification of HTTP Digest authentication

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Sep 2004 10:02:01 -0400

Hi,

We recently got a bug report concerning the formatting of Digest
authentication parameters in the CUPS HTTP headers.  Specifically,
we currently separate Digest parameters with whitespace, but the
bug report says that we should be using commas.

The ABNF in RFC 2617 does not specify any separator characters
between parameters, but the examples use both commas and spaces.

So, I'd like to know what the "official" position is on this, and
then propose corresponding changes to the RFC to clarify it.

Thanks!

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com

---

From: Jim Luther <[email-masked]>
Date: Fri, 10 Sep 2004 07:59:20 -0700

I believe the answer is: Multiple parameters in a challenge are 
separated by separated by one or more commas (",") and OPTIONAL linear 
white space (LWS).

That's because...

rcf2617, section 1.1 points to the augmented BNF section 2.1 of rfc2616.

rfc2617, section 1.2 gives this rule for parameters:
     auth-param     = token "=" ( token | quoted-string )
and this rule for a challenge with 1 or more parameters:
     challenge      = auth-scheme 1*SP 1#auth-param

and so rules for parameters are covered by the #rule as explained in 
rfc2616, section 2.1:
#rule
     A construct "#" is defined, similar to "*", for defining lists of
     elements. The full form is "<n>#<m>element" indicating at least
     <n> and at most <m> elements, each separated by one or more commas
     (",") and OPTIONAL linear white space (LWS). This makes the usual
     form of lists very easy; a rule such as
         ( *LWS element *( *LWS "," *LWS element ))
     can be shown as
         1#element
     Wherever this construct is used, null elements are allowed, but do
     not contribute to the count of elements present. That is,
     "(element), , (element) " is permitted, but counts as only two
     elements. Therefore, where at least one element is required, at
     least one non-null element MUST be present. Default values are 0
     and infinity so that "#element" allows any number, including zero;
     "1#element" requires at least one; and "1#2element" allows one or
     two.

There is also an errata document for rfc2616 and rfc2617 at 
<http://purl.org/NET/http-errata> which contains a few corrections to 
the ABNF.

The trickiest parsing I found was detecting the difference between 
another auth-param and the beginning of a new challenge in a 
WWW-Authenticate header or a Proxy-Authenticate header containing more 
than one challenge.

Hope that helps...

- Jim