On Sep 14, 2016 12:59 PM, "Ruediger Pluem" <rpl...@apache.org> wrote: > > On 09/14/2016 07:17 PM, Jacob Champion wrote: > > > > I think that's bad from a documentation and usability standpoint. If WHATWG (hypothetically) decided to bless more > > exceptions to the RFC, would we follow suit with StrictURI? Is StrictURI *really* an option to follow the RFCs to the > > letter, or is it an option to try to do things as correctly as we can without breaking major browsers? > > I think it should be the later one in this case. I see no real use case for an option that makes it fail with major > browsers.
I've reached the same conclusion and will not pursue the Firefox exception, so that everyone can use these results for reference. StrictURI can be used by app developers, UA developers, content authors etc to verify their conformance. Note that in the URI Path segment, none of these wonky exceptions actually matter, if the content authors, app devs and admins do not create valid URIs without proper encoding. E.g. StrictURI is perfectly usable for most path resources of most conventional sites. Even if resources have these unsafe chars, if they correctly encode their own href= it will work fine. It is the complete failure in all browsers to correctly submit query args that make this all unusable. If and when browsers correct their encoding, this will become usable in production. We can clearly document this in the directive docs and leave StrictURI not-recommended for general deployments. When we add a strict mode in apr 1.next, we can validate per-segment, and even exclude the query args from strict behavior, if desired. But that's beyond the scope of what I propose in the short term.
