Re: URL, URI and the w3c

[Stefan Eissing <[e-mail]>]

> Am 14.06.2022 um 23:46 schrieb Tim Bray <[e-mail]>:
> 
> I was saying something more specific. AFAIK, an 3986-conforming URL will generally be interpreted by browsers in the way its author intended.
> 
> I went through https://github.com/bagder/docs/blob/master/URL-interop.md and let me revise that slightly: Any 3986-conforming URL that is plausible for inclusion in an Internet-Draft will generally be interpreted by browsers in the way its author intended.  I was having trouble finding counter-examples but am prepared to believe that I'm missing something obvious.

The direction 3986 -> TWUS is ok. The reverse is what the 'living' TWUS raison d'etre is: how to transform the junk that people enter in the address bar and the junk that people/software put into HTML's href attributes into a 3896 url when talking to servers. No RFC addresses that problem and user agents have a real need to have that defined in a common way for interop between browsers. In order to reject at least part of the junk, no browser in the past could to that alone. User would always raise issues with "But it works in XXX!".


This process, define common grounds on what to do with the surprises users/software feeds us, was not really fit for a standard. The surprises always continued. Maybe it's more settled now. And the "living" part of TWUS fades away. I don't know.


The problem looking ahead is that the technical term "URL" has been polluted. It is not clear what standard it refers to. Also, usage of TWUS urls is leaking from browsers into other parts. HTTP clients, like curl, are expected to work with URLs "just as the browsers do". This is a not unreasonable demand from users who are unaware of the finer details. Once you start accepting TWUS urls on the command line, where does it stop? If you see a non-3986 'Location' header, what to do with it? Should you follow its TWUS interpretation or fail the request?


All this mess could still be a happy place if it weren't for SECURITY. Authorization likes it rules to be clean and simple. If its checks assume 3986 and other parts of a system allow TWUS (or vice versa), this becomes exploitable. (and 3986 alone is already tricky for programmers who use terms like "percent-decoded URLs" as if those would really exist!)



> Am 14.06.2022 um 11:55 schrieb Roberto Polli <[e-mail]>:
> 
> Which spec should I reference in an HTTP derived protocol
> such as OAuth2 ?

I can see only drawbacks in using TWUS for REST APIs or other software-generated documents/request/responses. Where user input is involved, TWUS offers a definition of how to go from there to 3896, if you cannot enforce it straight away.

Kind Regards,
Stefan