Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)

[Julian Reschke <[e-mail]>]

On 2015-02-18 23:46, Pete Resnick wrote:
> On 2/18/15 4:27 PM, Julian Reschke wrote:
>
>>>     Furthermore, a user-id containing a colon character is invalid, as
>>>     recipients will split the user-pass at the first occurrence of a
>>>     colon character.  Note that many user agents however will accept a
>>>     colon in user-id, thereby producing a user-pass string that
>>>     recipients will likely treat in a way not intended by the user.
>>
>> I just tested Firefox, Chrome, and IE. All of them accept colons in
>> user ids and do exactly what the spec currently says.
>
> You mean all of them simply take the user-id, add a colon, add the
> password, and when the server gets it, the server interprets everything
> before the first colon as the user-id and (almost always) fails? That is
> to say, user-ids with colons simply don't work?

That's what these UAs do. I don't know why they do it; perhaps it 
"works" (for some definition of "works") with some servers.

>> It seems pointless to me to say "MUST NOT" when it's widely
>> implemented that way. In a new protocol I'd prefer and mandate "fail
>> early", but this is not a new protocol.
>
> I guess I'm lost on the distinction between:
>
>     A user-id containing a colon does not work.

I don't say "does not work", but "Note that many user agents however 
will accept a colon in user-id, thereby producing a user-pass string 
that recipients will likely treat in a way not intended by the user.". I 
think that's an accurate description of reality.

> and
>
>     A user-id containing a colon MUST NOT be used.
>
> They are semantically identical, AFAICT.
>
> "MUST NOT" does not mean the Internet Police will come to take you away.
> "MUST NOT" means "this won't work".

Ahem, no, that's not what "MUST NOT" means.

Best regards, Julian