Re: #516 note about WWW-A parsing potentially misleading

On 2013-10-30 15:40, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> Hi there,
>>
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-24.html#rfc.section.4.4>:
>>
>> "User agents are advised to take special care in parsing the
>> WWW-Authenticate field value as it might contain more than one
>> challenge, or if more than one WWW-Authenticate header field is
>> provided, the contents of a challenge itself can contain a
>> comma-separated list of authentication parameters."
>>
>> This is text that we copied from RFC 2616
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.47>).
>> However, isn't the
>>
>> "...if more than one WWW-Authenticate header field is provided..."
>>
>> incorrect?
>>
>> What's contained in a challenge does not depend on the number of header
>> field instances, after all.
>
> The intent may have been to emphasise that having only one challenge per
> WWW-Authenticate header does not mean no special care has to be taken. I
> agree that it can be confusing; replacing the sub clause by "and" should
> be fine.

Not sure what your proposal is.

How about:

"User agents are advised to take special care in parsing the
WWW-Authenticate header field, as each field value can contain more than 
one challenge, and the header field itself can occur multiple times. 
Furthermore, the contents of a single challenge can contain a
comma-separated list of authentication parameters."

> (User agents should also take special care handling multiple headers; it
> can make a difference whether you parse them individually or merge them
> first and then parse the whole value; e.g. two individually malformed
> values might turn into a well-formed value. But WWW-Authenticate is not
> special in that regard.)

That is true, but as you say not specific to this one. The way to 
address this would to require validation of the header field instances 
before re-combining them, but then *that* requires knowledge of the 
field values' syntax.

Best regards, Julian

Received on Wednesday, 30 October 2013 14:59:23 UTC