Re: Adding user@ to HTTP[S] URIs

[James Fuller <[e-mail]>]

On Sun, 26 Jan 2020 at 11:03, Rick van Rein <[e-mail]> wrote:
> I know, but this kind of thinking is always hindering HTTP progress or,
> more in general, the development of any client/server protocol in use.
> This style of thought is not helpful during innovation, I think.

If I understood correctly, what is being proposed is instead of (using
prev response examples):

  https://family.redbarn.org/~vixie/
or
  https://family.redbarn.org/@vixie/

one may perform an HTTP request with either of the following:

  https://[e-mail]
or
  GET /index.html HTTP/1.1
  Host: family.redbarn.org
  User: vixie

> Note that what I am tackling here is based on misinterpretation of
> RFC3986, so it is a bug that ought to be fixed.  Also note that nothing
> is breaking by adding this facilty, only enforcing its use could.

what a URI can and cannot be (or should be) is a minefield with
respect to specifications vs what we have in the 'real world' eg. a
mixture of interpretation from several specs, what the major browser
vendors support with a dash of adhoc. A few years back Daniel Stenberg
overview still applies:

  https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/

I only mention this link because your spec seems to imply that URI (as
a technology) have a single, stable, canonical specification
describing behaviour from which we can incrementally define/refactor
new behavior from... that is not the case.

> Users who do have a compliant user agent can immediately experience the
> benefits for their own use, against their own sites.  That might be
> their own IDP, but the support might explode when large providers
> support it, as in https://[e-mail] for access to webmail.

I think I completely understand the rationale for your proposal ...
just 'old man cranky' on the reality of adopting such a change.

Some observations:

The userinfo section is optional with scope and context related to the
denoted host ... as prev mentioned should not be transmitted.

   authority = [userinfo@]host[:port]

In HTTP we often conflate the 'User' of a software system/application
as equiv to a 'user' against a specific host in terms of an HTTP
conversation ...  though the semantics are important eg. links, logs,
search engines will hover up such information. That may create an
unpredicted new burden to redact (for privacy or security purposes) or
assist in replay (where Authorization headers are being stripped).
Then I wonder what should happen when User: Mary1 has an authorisation
with user="mary" ... having such drift may confuse things.

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. Existing servers, clients, cache (middle
box or otherwise) may have to cater for this change.

URI's are 'forever' and used in a lot (a lot) of different places ...
eg. what happens if a URI identifying a resource is then used
(unintentionally) in some other technology (semweb, rdf triple,
namespaces, etc etc etc) ...  it may not be in scope to define that
behaviour but might be worth thinking a bit beyond a 'browser hitting
a web server' type of use case.

(no doubt due to my own ignorance) I struggle to see the benefits over
using existing 'machinery' and there maybe 'dragons' ...

,Jim

>
> Thanks,
>  -Rick
>
>
> > Consider: If a user clicks on your link, some user agents will send:
> >
> > GET /index.html HTTP/1.1
> > Host: example.com
> > User: john
> >
> > And others will send (because they choose not to implement the feature):
> >
> > GET /index.html HTTP/1.1
> > Host: example.com
> >
> > So what functionality is this offering, if servers can’t rely on user agents sending the header?
> >
> > There’s an easy solution, just put it in the hier-part:
> >
> > http://example.com/~john/index.html
> >
> > Or maybe define a standard that allows the _server_ to specify: “URIs of this format <http://example.com/~{user}/> belong to the specified user”
> >
> > Austin Wright.
> >
> >
> >> On Jan 25, 2020, at 08:59, Rick van Rein <[e-mail]> wrote:
> >>
> >> Hi Daniel,
> >>
> >>> You can't fix this simply by saying that setting the name part of the
> >>> userinfo in a HTTP URI is OK. HTTP has no established way to send a
> >>> user name outside of authentication.
> >> Exactly.  That's why I started this thread with an Internet Draft,
> >> https://datatracker.ietf.org/doc/draft-vanrein-http-unauth-user/
> >>
> >> For http://[e-mail]/index.html it sends
> >>
> >> GET /index.html HTTP/1.1
> >> Host: example.com
> >> User: john
> >>
> >>
> >> Cheers,
> >> -Rick
> >>
> >
>