W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: Editorial issues with RFC 7616

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 30 Jun 2021 14:23:05 +0200
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <2366f90d-dec0-13c5-1e70-e836e5500fac@gmx.de>
Am 30.06.2021 um 14:16 schrieb Christer Holmberg:
> Hi,
>>> Ok, but how does it work in general, then?
>>> For example, assume I have a parameter foo that allows both token and quoted-string parameter values.
>>> I then define/register the value "BAR". Does that mean that "BaR", "bar", "Bar" etc are now allowed - unless explicitly indicated, as in the case of charset?
>>> ...
>> They are "allowed" in any case (syntactically).
> Sure. Bad wording.  What I meant was whether they are semantically identical.
>> If the parameter is defined to be case-sensitive, then yes, they are different. Otherwise they would be equivalent.
>> Note that that is true for the token form as well (it allows both upper and lowercase).
> So, what are the case-sensitivity rules for 'userhash', 'domain', 'nonce', 'opaque' and 'algorithm' auth parameters?
> Section 2.1 of RFC 7235 *DOES* say:
>     "Authentication parameters are name=value pairs, where the name token
>     is matched case-insensitively, and each parameter name MUST only
>     occur once per challenge."
> So, based on that one could assume that case-insensitive is the default, unless otherwise explicitly specified. So far so good.

No, that's not what it says. That statement is about the parameter *name*.

In general, if something is case-insensitive, it needs to be stated

> However, for a couple of parameter there is explicit text saying that the value is case-insensitive:
> For the 'stale' parameter RFC 7616 explicitly says:
>        "A case-insensitive flag indicating that the previous request from
>        the client was rejected because the nonce value was stale."


> For the 'charset' parameter RFC 7617 (which, btw, is only informatively referenced by RFC 7616) explicitly says:
>     "The only allowed value is "UTF-8"; it is to be matched case-
>     insensitively (see [RFC2978], Section 2.3)."
> So, assuming that the default is case-insensitive, perhaps that can be clarified in an errata. I think it is related to my issue Q1.

Unless stated, things are case-sensitive, so I really don't see an issue
here yet.

Best regards, Julian
Received on Wednesday, 30 June 2021 12:23:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 30 June 2021 12:23:22 UTC