Re: HTTP/1.1 strict ruleset

On Wed, Aug 03, 2016 at 06:58:26PM -0500, William A Rowe Jr wrote: > > I see a lot of value in logging when not applying the strict parsing, > > so you can passively assess your traffic for a day/week/month. > > That requires additional CPU, and significantly more code complexity. > In fact, I

Re: HTTP/1.1 strict ruleset

> Well, is there any point of detailing the specific offending field names? > The bad text received? To the consumer in the response error message, > or strictly to the logs? I don't think it's too important in the response. > We should log (once) the cause of a 400, but are the details

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote: > > > 2. leave the default as 'not-strict'? Seems we should most > >strongly recommend that the server observe RFC's 2068, > >2616 and 723x, and not tolerate ancient behavior by default > >unless the admin insists

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote: > On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr > wrote: > > So it seems pretty absurd we are coming back to this over > > three years later, but is there any reason to preserve pre-RFC 2068 > >

Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr wrote: > So it seems pretty absurd we are coming back to this over > three years later, but is there any reason to preserve pre-RFC 2068 > behaviors? I appreciate that Stefan was trying to avoid harming > existing deployment

HTTP/1.1 strict ruleset

So it seems pretty absurd we are coming back to this over three years later, but is there any reason to preserve pre-RFC 2068 behaviors? I appreciate that Stefan was trying to avoid harming existing deployment scenarios, but even as I'm about to propose that we backport all of this to 2.4 and 2.2,

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 4:58 PM, William A Rowe Jr wrote: > On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion >> wrote: >> >>> >>> I don't think this is an equivalent transformation. More logic below >>> this case relies on the last_field NULL check, and

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr wrote: > On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote: > >> > On Aug 3, 2016, at 11:44 AM, Jacob Champion >> wrote: >> > >> > On 07/31/2016 09:18 AM, William A Rowe Jr

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 4:29 PM, William A Rowe Jr wrote: > On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion > wrote: > >> On 08/03/2016 09:46 AM, wr...@apache.org wrote: >> >>> Modified: httpd/httpd/trunk/server/protocol.c >>> URL: >>>

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion wrote: > On 08/03/2016 09:46 AM, wr...@apache.org wrote: > >> Modified: httpd/httpd/trunk/server/protocol.c >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1755098=1755097=1755098=diff >> >>

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote: > > On Aug 3, 2016, at 11:44 AM, Jacob Champion > wrote: > > > > On 07/31/2016 09:18 AM, William A Rowe Jr wrote: > >>> So all the trailing SP/HTAB are part of obs-fold IMHO. > >>> Should we replace

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On 08/03/2016 09:46 AM, wr...@apache.org wrote: Modified: httpd/httpd/trunk/server/protocol.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1755098=1755097=1755098=diff == ---

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 12:05 PM, Jacob Champion wrote: So if there is an HTAB directly *before* the obs-fold CRLF, we should not try to replace with a SP? Ad never mind here; looks like we already strip trailing OWS from the end of the line before the fold. That'll teach me to theorycraft before

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 12:05 PM, Jacob Champion wrote: Right, I was just wondering out loud if condensing into a single space could give anyone the chance to defeat a header length check in a multi-layered system. It's admittedly a pretty "tinfoil hat" concern. Never mind. It would need to be the other

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 08/03/2016 11:53 AM, Roy T. Fielding wrote: Replacing each byte with a separate space (as opposed to condensing into a single space) *might* help prevent adversaries from playing games with header length checks in more complicated/layered systems. That's probably a stretch though. And if we

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

> On Aug 3, 2016, at 11:44 AM, Jacob Champion wrote: > > On 07/31/2016 09:18 AM, William A Rowe Jr wrote: >>> So all the trailing SP/HTAB are part of obs-fold IMHO. >>> Should we replace all of them (plus the CRLF) with a single SP or with >>> as many SP? >> >> Hmmm...

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On 07/31/2016 09:18 AM, William A Rowe Jr wrote: So all the trailing SP/HTAB are part of obs-fold IMHO. Should we replace all of them (plus the CRLF) with a single SP or with as many SP? Hmmm... Good point. Advancing over them in our HTTP_STRICT mode seems best, if we have a consensus on this.

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

On Wed, Aug 3, 2016 at 12:19 PM, William A Rowe Jr wrote: > On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett wrote: > >> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr >> wrote: >> >> > Worse, in http 2.4, the first two registered

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett wrote: > On 18 Jul 2016, at 6:32 PM, William A Rowe Jr wrote: > > > Worse, in http 2.4, the first two registered methods collide with BREW > and WHEN. That said, the 'fix', if we wanted to resolve it, is to

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

On 18 Jul 2016, at 6:32 PM, William A Rowe Jr wrote: > Worse, in http 2.4, the first two registered methods collide with BREW and > WHEN. That said, the 'fix', if we wanted to resolve it, is to use M_INVALID > +3 as the first value. I’m not seeing the problem here, there

Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c

2016-08-03 1:50 GMT+02:00 Yann Ylavic : > On Tue, Aug 2, 2016 at 6:58 PM, Luca Toscano > wrote: > > > > 2016-08-02 17:54 GMT+02:00 Yann Ylavic : > >> > >> On Tue, Aug 2, 2016 at 5:05 PM, Yann Ylavic >

Re: svn commit: r1754916 - in /httpd/test/mod_h2/trunk: conf/sites/test.example.org.conf test/go/ test/go/get.go test/go/test_get.sh test/test.sh test/test_common.sh

We discovered some incompatibilities when testing the current go RC against 2.4.23. That's why I am adding go to the list of test clients. I would also like to add Python's hyper, given time. Maybe even headless browsers. The reasons why it's important is that current tests rely mainly on curl