W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: Adding user@ to HTTP[S] URIs

From: Rick van Rein <rick@openfortress.nl>
Date: Thu, 30 Jan 2020 00:07:33 +0100
Message-ID: <5E321035.50901@openfortress.nl>
To: Amos Jeffries <squid3@treenet.co.nz>, James Fuller <jim@webcomposite.com>, Daniel Stenberg <daniel@haxx.se>
CC: ietf-http-wg@w3.org
Hello Daniel, James and Amos,

I think I resolved the challenges that you posed.  Thank you for making
me think harder and (I believe) improve on the proposal.

I stopped fussing about colons in the userinfo and left that to RFC 3986
and perhaps HTTPbis; I changed the contents of the User header to the
beginning of the userinfo up to any colon; I allowed the header value to
be an empty string, and be supplied by compliant user agents
if-and-only-if there is a userinfo component in the target URI.

You indicated a conflict with Basic authentication.  However, it is
possible to send both the User header and Basic authentication.

In addition to the changes noted, I explained

Appendix B.  Compatibility with Basic Authentication

   This appendix is informative.

   Basic authentication is regularly used as a quick and easy HTTP
   authentication technique.  Several user agents continue to support it
   with the "user:password@" URI prefix to a hostname, despite its
   deprecation.  This specification imposes no new constraints on this
   practice; it merely prescribes to send the User header field,
   possibly in addition to an existing pattern of Basic authentication.

   The mapping from resource names to actual resources is the
   prerogative of the server.  A server supportive of resource selection
   through Basic authentication could ignore the User header field and
   still comply with this specification.  A server that does recognise
   the User header field would use it to locate a resource, before
   deciding about access control to that resource; this may raise
   authentication requirements, and select schemes that could be
   supported.  At this time, it may or may not welcome an added Basic
   authentication attempt.  All this is server configuration.

   This flexibility can support a transition from Basic authentication
   to User header fields on the server, and allows client software to
   follow suit by first adding the User header, and later dropping the
   deprated pattern with "user:password" in the userinfo component of a
   URI.  Server administrators have a free choice to gradually phase out
   clients or client configurations that adhere to older and possibly
   deprecated usage patterns.

   Sending both the User header and Basic authentication is only to be
   expected from user agents who conflate resource userinfo with
   authentication user.  Such user agents will be less flexible, and
   will not be able to support more advanced usage patterns that
   separate these concepts, such as shared/group resources addressed
   with the User: header field and, when desired, authentication through
   an independent set of headers.  Among the tools to drive such
   patterns could be the negotiation of more advanced mechanisms, even
   just Digest authentication.

@James, @Amos

You were concerned about finding the same resource on all accounts, for
instance one client's PUT should end up in the same resource as another
one's.  Having allowed empty values to the User header, I could write:

Appendix C.  Compatibility with RESTful Patterns

   This appendix is informative.

   Whether and how the User header is interpreted is the prerogative of
   the server.  The server will translate resources in the same manner
   when provided with the same User header, and may do so without regard
   for the method used.  The main concern is now if it will be addressed
   in the same manner in every case.  This depends on the user agents.

   Development environments make sending the User header field simple,
   and so application support is as easy as the applications are
   flexible.  Binary user agents and especially ones that may lag behind
   in updates therefore need some care for backward compatibility

   The compatibility can be guaranteed for host names that always
   require a User header; such resources may be described with a URI
   holding a present but empty userinfo field.  Failure to send a User
   header to such resources when the URI holds one can be assumed to
   have originated from a user agent that support it.  When an offer for
   Basic authentication is presented, it may be interpreted as the older
   approach to userinfo, and treated as a substitute for the User
   header.  If neither is offered, an error may be reported, or control
   redirected to another means of selecting a resource user.

   This indicates that the server is able to detect possible problems,
   and can avoid accidentally binding a request to an unintended
   resource as a result of a missing User header.

   Under the fallback, resources gain an alias under a local convention.
   The URI form with a userinfo field has more semantics, and offers
   better interpretation options to clients, so among aliases this is
   the form that should be treated as the canonical URI.

You requested more text about caching.  Most of it is orthogonal to the
User header, but the following things may make sense to mention in any
case.  Please let me know if I am overlooking things.

Appendix D.  Compatibility with Caching

   This appendix is informative.

   Whether and how the User header is used to find resources is the
   prerogative of its server.  A conservative cache design might insert
   the User header value in its request URI, but lose the capability of
   seeing the equivalence of a resource as perceived by the server.  The
   inclusion of the name "User" in the Vary header of the response
   provides a more accurate cache instruction.

   Whether a result is "private" is independent of the User header, as
   that only signifies a refinement of the resource name space on the
   server.  The rules that signify authentication as default indicator
   of privacy is orthogonal to the User header.  This is one reason why
   it is good to separate resource user and authentication user; Basic
   authentication may work to select resources, but it reduces cache

The complete proposal is moving towards one where the current handling
is the default handling and the distinction between resource userid and
authentication userid is an explicit advanced case.  Clients send both
and servers get to choose, but it is up to the client to select the
advanced case.  The realm already offers the proper key to store such
choices, specific to the User header value and server-proposed realm.

Thanks for helping to develop this idea!

Received on Wednesday, 29 January 2020 23:07:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 29 January 2020 23:07:56 UTC