W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: Clarification of HTTP Digest authentication

From: Jim Luther <luther.j@apple.com>
Date: Fri, 10 Sep 2004 07:59:20 -0700
Message-Id: <FE85FED2-0339-11D9-B213-000A95DC65E0@apple.com>
Cc: ietf-http-wg@w3.org
To: Michael Sweet <mike@easysw.com>

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:
     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
     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

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

On Sep 10, 2004, at 7:02 AM, Michael Sweet wrote:

> 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!
Received on Friday, 10 September 2004 14:59:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC