Re: Adding user@ to HTTP[S] URIs

Hi Amos,

>> 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?

I did not mean any disrespect; sorry if it came across like that.  I
know how slowly protocols change, as a result of user base.

>> 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.
> 
> It is not *wrong*, so much as it is burdened by the large amount of
> historic software relying on and assuming different definitions.

I know this effect, but am nonetheless surprised that 0.9 is still around.

>>> 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://john@example.com/" 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.

Ah, that is a clear question, will need to think it over.

> 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.

Will look into that; of course I am open to text by others too.

FWIW, the next iteration will address compatibility with Basic.

-Rick

Received on Monday, 27 January 2020 16:14:25 UTC