Re: T of 2.4.24

On Thu, Dec 8, 2016 at 7:16 PM, William A Rowe Jr wrote: > > It does raise the question again of whether the httpd project can distribute > a source code package on www.apache.org/dist/httpd/ which is not voted > on by the project, and whether it violates the spirit of the

Re: T of 2.4.24

On Thu, Dec 8, 2016 at 12:16 PM, William A Rowe Jr wrote: > On Thu, Dec 8, 2016 at 12:03 PM, Jim Jagielski wrote: > >> AFAICT there is no consensus. But is this really a blocker? > > > I don't know, expat is at 2.2.0 and PCRE is at 8.39 with significant >

Re: svn commit: r1773293 - /httpd/httpd/trunk/modules/http/http_filters.c

On Thu, Dec 8, 2016 at 1:57 PM, wrote: > Author: covener > Date: Thu Dec 8 19:57:57 2016 > New Revision: 1773293 > > URL: http://svn.apache.org/viewvc?rev=1773293=rev > Log: > change error handling for bad resp headers > > - avoid looping between ap_die and the http filter

Re: svn commit: r1773293 - /httpd/httpd/trunk/modules/http/http_filters.c

On 12/08/2016 02:06 PM, Eric Covener wrote: On Thu, Dec 8, 2016 at 4:55 PM, Jacob Champion wrote: Hmm, I suppose that if something like Transfer-/Content-Encoding is one of the headers to get axed here, we'll end up breaking the protocol entirely if and when we push out

Re: svn commit: r1773293 - /httpd/httpd/trunk/modules/http/http_filters.c

On Thu, Dec 8, 2016 at 4:55 PM, Jacob Champion wrote: > Hmm, I suppose that if something like Transfer-/Content-Encoding is one of > the headers to get axed here, we'll end up breaking the protocol entirely if > and when we push out the original response body... Probably

Re: svn commit: r1773293 - /httpd/httpd/trunk/modules/http/http_filters.c

On 12/08/2016 11:57 AM, cove...@apache.org wrote: Author: covener Date: Thu Dec 8 19:57:57 2016 New Revision: 1773293 URL: http://svn.apache.org/viewvc?rev=1773293=rev Log: change error handling for bad resp headers - avoid looping between ap_die and the http filter - remove the header that

Re: svn commit: r1773163 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ modules/http/http_filters.c

It should be complete enough to apply complete to httpd-2.4.x. On Dec 8, 2016 1:32 PM, "Eric Covener" wrote: > On Wed, Dec 7, 2016 at 6:40 PM, wrote: > > Author: wrowe > > Date: Wed Dec 7 23:40:20 2016 > > New Revision: 1773163 > > > > URL:

Re: 2.4 HEAD: some looping issue with check_headers()

On Thu, Dec 8, 2016 at 2:34 PM, Jacob Champion wrote: > On 12/08/2016 11:14 AM, Eric Covener wrote: >> >> On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr >> wrote: >>> >>> Still, I think we want to add a guard to rip out the offending header >>> and

Re: 2.4 HEAD: some looping issue with check_headers()

On 12/08/2016 11:14 AM, Eric Covener wrote: On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr wrote: Still, I think we want to add a guard to rip out the offending header and not ap_die() in handling a 500 error, that's quite the loop, and if you could create the problem,

Re: svn commit: r1773163 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ modules/http/http_filters.c

On Wed, Dec 7, 2016 at 6:40 PM, wrote: > Author: wrowe > Date: Wed Dec 7 23:40:20 2016 > New Revision: 1773163 > > URL: http://svn.apache.org/viewvc?rev=1773163=rev > Log: > After eliminating unusual whitespace in Unsafe mode (e.g. \f \v), we are left > with the same behavior

Re: 2.4 HEAD: some looping issue with check_headers()

On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr wrote: > Still, I think we want to add a guard to rip out the offending header > and not ap_die() in handling a 500 error, that's quite the loop, and > if you could create the problem, so can another unsuspecting admin. Is

Re: 2.4 HEAD: some looping issue with check_headers()

On Thu, Dec 8, 2016 at 12:49 PM, Eric Covener wrote: > On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote: > > This is even after trying to zap the offending header before ap_die. > > I think this is more about how I am injecting the bad characters -- It >

Re: 2.4 HEAD: some looping issue with check_headers()

On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote: > This is even after trying to zap the offending header before ap_die. I think this is more about how I am injecting the bad characters -- It is re-running after the ap_die. -- Eric Covener cove...@gmail.com

Re: T of 2.4.24

Scratch that... Instead, I plan on doing it on Monday, to provide some additional time for some things to get locked down and resolved. My apologies for those waiting for 2.4.24... > On Dec 8, 2016, at 9:55 AM, Jim Jagielski wrote: > > Things are looking good for a T of

Re: 2.4 HEAD: some looping issue with check_headers()

I should mention I was actually "on" trunk because I thought there'd be a quick fix. But the relevant stuff is recently backported On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener wrote: > I am playing with check_headers() and injecting bad characters, and I > am getting some

2.4 HEAD: some looping issue with check_headers()

I am playing with check_headers() and injecting bad characters, and I am getting some looping: #2155 0x0048af80 in ap_http_header_filter (f=0x7fffc80061d0, b=0x7fffc09c2bd8) at http_filters.c:1262 #2156 0x004396d0 in ap_pass_brigade (next=0x7fffc80061d0, bb=0x7fffc09c2bd8) at

Re: T of 2.4.24

On Thu, Dec 8, 2016 at 12:03 PM, Jim Jagielski wrote: > AFAICT there is no consensus. But is this really a blocker? I don't know, expat is at 2.2.0 and PCRE is at 8.39 with significant vulnerability fixes (everyone seems very enamored with fuzz generators this past few

Re: T of 2.4.24

AFAICT there is no consensus. But is this really a blocker? > On Dec 8, 2016, at 12:38 PM, William A Rowe Jr wrote: > > On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski wrote: > Things are looking good for a T of 2.4.24 sometime late > today. > > If you

Re: T of 2.4.24

On Thu, Dec 8, 2016 at 8:55 AM, Jim Jagielski wrote: > Things are looking good for a T of 2.4.24 sometime late > today. > > If you have any issues or concerns, let me know asap. > Do we have any consensus on dropping the stale and vulnerable expat or pcre packages from the

Re: PCRE 10 and puzzling edge cases

I've beaten my head against this wall for a bit longer, and came up with several places where pcre2 changed return types for void *what query interogations (especially from int to uint32, badness on x86_64-linux). The attached patch picks up these bad void * type assignments. Still no tremendous

T of 2.4.24

Things are looking good for a T of 2.4.24 sometime late today. If you have any issues or concerns, let me know asap.

Re: Content-Length header for HTTP 204 and 1xx status codes

Hi everybody, thanks a lot for the useful feedback. Quoting Jacob from another thread: 2016-12-08 0:04 GMT+01:00 Jacob Champion : > > > I thought the original bug report was related to 204 processing only, and > then Luca asked if his patch should also include

Re: About Interim Response Headers (was: Content-Length header for 1xx status codes)

> Am 08.12.2016 um 11:25 schrieb Yann Ylavic : > > On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr wrote: >> On Dec 7, 2016 6:23 PM, "Jacob Champion" wrote: >> >> On 12/07/2016 04:00 PM, William A Rowe Jr wrote: >>> >>>

Re: About Interim Response Headers (was: Content-Length header for 1xx status codes)

On Thu, Dec 8, 2016 at 3:12 AM, William A Rowe Jr wrote: > On Dec 7, 2016 6:23 PM, "Jacob Champion" wrote: > > On 12/07/2016 04:00 PM, William A Rowe Jr wrote: >> >> Consider for a moment the case of an HTTP/1.1 upgrade request >> unrecognized by a