Re: Adding user@ to HTTP[S] URIs

[Amos Jeffries <[e-mail]>]

On 28/01/20 1:02 am, Rick van Rein wrote:
> Hi James,
> 
> Thanks for your cautious response.
> 
>> If I understood correctly, what is being proposed is instead of (using
>> prev response examples):
> 
> Not instead of, but in addition to.  I have no quarrel with existing
> habits, I just want also be able to express things with more semantics,
> with broader validity.
> 
> The treatment of user identities does not add something that cannot also
> be done under other conventions.  However, these other conventions are
> local, and tighten the relations between parties and reduce the
> opportunity for automation, for being systematic, for solving things
> over a broad range.
> 
> My angle on this is from architecting an identity model that spans more
> protocols than just the web.  Every time I look at HTTP, it seems to
> have invented its own wheels and not be willing to mingle with the other
> protocols.

How many of those other protocols are newer than HTTP though?

RFC 3986 specification also is itself much newer than HTTP/. Back when
HTTP/1.0 was documented the URL syntax was defined by RFC 1738 which said:
"
   In general, URLs are written as follows:

       <scheme>:<scheme-specific-part>
"
...
"
3.1. Common Internet Scheme Syntax

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>

"

And then because HTTP/0.9 practices predated even this spec ...
"
   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

...  No user name or password is allowed.
"

HTTP has a long tail of infrastructure to support. Which includes
infrastructure designed and assuming those definitions. Some following
the RFC1738 no user:password@ section requirement. Some following the
common-URI  user:password@ requirement. Some following the RFC3986
adjustments.

The RFC723* documents went back to that original RFC1738 definition to
resolve these problems and ensure best interoperability. It is unlikely
to have been long enough for that long tail of software to have churned
out of existence yet and make the field usable again. Meanwhile we have
pseudo-headers now for URL parts.


NP: I am supportive of the effort to get a standard for translating
between URL syntaxes. But worried the authors view is badly mistaken
about the situation from HTTP viewpoint.



> 
>> Then I wonder what should happen when User: Mary1 has an authorisation
>> with user="mary" ... having such drift may confuse things.
> 
> In the example I gave, they are identities from different name spaces;
> and they are linked by the server, presumably through some kind of ACL.
> That ACL would say things like "Mary1" is the resource being addressed,
> and it accepts/rejects users who authenticated as "mary".  ACLs tend to
> be pretty accurate in linking resources and users ;-)
> 
> This decoupling is at the heart of my reasoning.  It makes sense in most
> of the protocols, but HTTP has, probably due to Basic/Digest
> authentication, gotten them mixed up.
> 

I think it is probably you that have the concepts mixed up.

As you should be able to see from the above text HTTP is *old*. From a
time when userinfo@ was outright forbidden through years when it means
exclusively Basic authentication credentials. Decades when there was not
much in the way of other authentication or authorization mechanisms
existing.

It is not *wrong*, so much as it is burdened by the large amount of
historic software relying on and assuming different definitions.
Software which is still hanging around. In the Squid Project we are only
just starting to see lack of push back against removing HTTP/0.9 support
sometime later this decade - gopher and FTP are still very much alive
and well.



>> It is not obvious how this change might affect idempotency eg. what
>> happens when Mary gets a different document then John based on routing
>> with the new User: header.
> 
> Idempotency means that doing the same thing again has no added effect.
> What does that mean here?
> 

That "PUT http://[e-mail]/" stores the correct document on the
server, in the correct place. Even when the server does not understand
the new header.

The client MUST NOT assume that the header works everywhere all the time.



>> Existing servers, clients, cache (middle
>> box or otherwise) may have to cater for this change.
> 
> Please let me know if the cache solution in the proposal is incomplete.
>  Please let me know if the statement that a server may ignore the User:
> header (and presumably present a fallback page) is insufficient.  Please
> let me know whatever concrete issue you are seeing that I missed!
> 

I see only use of Vary header for caching.

It would be useful to add text clarifying non-GET requests cannot depend
on the header being obeyed. Such as the above a client using PUT.


Amos