httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]
Date Wed, 14 Sep 2016 19:17:57 GMT
On Sep 14, 2016 12:59 PM, "Ruediger Pluem" <rpluem@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.

Mime
View raw message