Re: draft-montenegro-httpbis-uri-encoding

Le Sam 22 mars 2014 00:30, Mark Nottingham a écrit :

> In particular, this seems like something that needs to be coupled to
> *where* the link originates; e.g., a browsers’ behaviour for a link from
> an address bar is likely to be different than that from an ‘a’ tag, and
> even again different from a JavaScript-generated link.

True.
What last decade unicode migration taught us, is that once you allow text
with undefined encoding in the pipeline, things are going to fail.
Encoding really wants to be end-to-end.

Still, this is little different from mime-types, where everyone relies on
mime-type hints for things to work well, but servers and web clients
sometimes have to infer them in less-than optimal ways to fill in the http
headers. Asking for url encoding to be defined at the http level (with a
fallback to a clear encoding default otherwise) is similar, with the
detection pushed to servers and web clients, which will presumably push
for better behaviour elsewhere to avoid being saddled with the heuristics
currently pushed on network nodes.

I'll add that we are living in an insecure world right now, that to
mitigate security problems everyone has been adding blacklists of
known-bad urls (from browsers to java to adobe reader to various security
extensions) but those blacklists rely on someone being able to review and
curate them. Which is obviously is a problem when you start to accept URLs
you're not able to decode or display in any reasonable manner.

Regards,

-- 
Nicolas Mailhot

Received on Monday, 24 March 2014 09:21:01 UTC