On Sep 13, 2016 3:36 AM, "Yann Ylavic" <ylavic....@gmail.com> wrote: > > On Tue, Sep 13, 2016 at 10:10 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > > > > > On 09/13/2016 04:19 AM, Eric Covener wrote: > >> On Mon, Sep 12, 2016 at 5:38 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > >>> It really seems that if a major client is not handling "|" correctly, we > >>> need to carve out an exception, > >> > >> +1 to allow it. > >> > >> For others who might hit a maze of closed/duped bug reports this one > >> is active this year: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1064700 > >> > > > > +1 > > +1, but I wouldn't put the exception in T_URI_RFC3986 (rather where it is used). > > We could still do things like: > ll = uri; > /* firefox bug exception w.r.t pipe */ > while ((ll = ap_scan_http_uri_safe(ll)) && *ll == '|') > ll++; > > Less simple, but it looks more correct to me, once firefox fixes its > bug we don't change T_URI_RFC3986's (expected) behaviour.
No, that's a mess. If an exception exists and isn't honored because that fn was called from a different module, it would be a nightmare. How we work around this in a new apr strict parser might look different. It is documented in the URI set as a (Firefox) bug. Fix in one line. Later undo this fix this in a single source file. It will have to live there for years, long after 2.2 is forgotten and to the end of 2.next's lifespan. Browsers don't change overnight. RHEL5 Firefox is certainly in use. If Firefox had fixed this before users were pushed TLS 1.2 updates for next year's SSL, that would be a different story. The theory was that only UI agent authors are in a position to fix a URI encoding bug. They ignore error response details. Changing this for end-users of Firefox is a total hassle. Thanks for the suggestion though.
