Re: Adding user@ to HTTP[S] URIs

[Rick van Rein <[e-mail]>]

Hey,

I think compatibility with the Basic/Digest pattern is actually quite easy.

>
>>
>> Browsers have no consistency in this usage pattern, so this is
>> definately a niche.
>
>
> Yes, but a niche with potentially a large amount of users.


Let's split those hairs; there is a clear distinction:

1. https://john:[e-mail]

2. https://[e-mail]

The 1. form is deprecated in RFC 3986 but, like so often, is popular for
quickfixes (that then to roll into production).  It is clearly
different from the 2. form because of the (RFC-abolished) colon.

The 2. form is less useful for password-based access with Curl, I'd say.
 It would start user interaction, which is pretty much what the 1. form
wants to avoid.  This is perfectly suitable for the User: header, which
never includes a colon.

If the 2. form is initially passed as User: header, the server either
recognises it and its ACL triggers the Basic/Digest interaction, or the
server does not recognise it, detects lacking authorisation and
explicitly triggers HTTP authentication, for instance Basic/Digest
interaction.  This is for servers that want authorisation; what the
User: header enables extra is to use the user name as a part of the
resource location.

You suggested it the other way around, which is certainly not workable
in general; I tried that.  Also, it mixes up authentication and resource
selection, which the modified form of the previous paragraph does not do.

If I didn't overlook things here, the two usage patterns can co-exist.
That means that the option to distinguish the forms may not even be
necessary, as long as the Basic/Digest submission may be part of a 2nd
round after being challenged.  It is up to the client whether it asks
for a password if that happens, and whether the user can still change
the uid from "sales" into "mary" (to reference the I-D example).


Cheers,
 -Rick