Re: Adding user@ to HTTP[S] URIs

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

Hi Michael,

Thanks for your positive response.

>> Most protocols support users under domain names, but HTTP does not.
> 
> Well, it *does* support users within the "path" part of the URL.  For instance, here's a page I just made for you, that's scoped to my user account:
> 
>     https://invisible.college/@toomim/hello-rick

These patterns are common, examples below, and that's why I believe that
we should support mapping users into the HTTP space.  It is useful if
the pattern can be consistent among servers, and in comparison with
other protocols, I think.  HTTP is missing that part of URL syntax.

Having a place to specify user name syntax and semantics is a good
example.  This can help to squash numerous attacks that may be tried
with the generic path-based format that you are showing.  We can then
restrict the grammar to that of a utf8-username in RFC 7542 and thus
exclude spaces, ":" and "@" and other junk and have it enforced (!) at
the HTTP level instead of in scripted applications of varying quality.

>> Usage patterns in the wild do suggest a desire to have this facility.
> 
> I didn't see any example usage patterns in the internet draft.  Can you provide some of them, so that we know what we are working with?

There are many examples of the URL-mapped form like you proposed, and
they seem to be telling that people (or groups) want to represent their
online identity in an HTTP URL.  They cannot be interpreted as user
names, and code to access it ends up with in-situ coding.

Conventionally structured mapping,
	https://www.cabrillo.edu/~rnolthenius/

Site-specific structure,
	https://nlnet.nl/people/leenaars.html
	https://people.utwente.nl/m.vankeulen
	https://www.facebook.com/dssvtartaros/

Unstructured mappings,
	http://catb.org/esr/
	http://rick.vanrein.org

These could be consistently represented as
	https://[e-mail]
	https://[e-mail]
	https://[e-mail]
	https://[e-mail]
	http://[e-mail]/esr
	http://[e-mail]

I pioneered this idea with a crude hack based on Basic authentication,
which is highly inconsistent across browsers because Basic and Digegst
have always misinterpreted the URL userinfo as authentication names,
	http://[e-mail]
	http://[e-mail]
	http://[e-mail]

I can include some examples in the next draft, no problem.


Thanks,
 -Rick