Re: Reject HTTP protocols >= 2.0 in ap_parse_request_line?

2020-06-17 Thread Roy T. Fielding
> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem wrote: > > I came across the question if we should not reject HTTP protocols >= 2.0 in > the request line when we parse it > in ap_parse_request_line. > This does not affect mod_http2 if loaded as HTTP/2.0 connections itself are > not parsed via

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Ruediger Pluem
On 6/17/20 3:11 PM, Ruediger Pluem wrote: > > > On 6/17/20 11:52 AM, Yann Ylavic wrote: >> On Wed, Jun 17, 2020 at 10:43 AM Joe Orton wrote: >>> And yes this makes me think if this kind of fake really makes sense. The need to reset 3 request_rec fields after

Fixed: apache/httpd#819 (trunk - dda688a)

2020-06-17 Thread Travis CI
Build Update for apache/httpd - Build: #819 Status: Fixed Duration: 7 mins and 14 secs Commit: dda688a (trunk) Author: Ruediger Pluem Message: * Reset the request_rec fields protocol, proto_num and the_request also in the error case and restructure code a

Still Failing: apache/httpd#818 (trunk - 2cec2d1)

2020-06-17 Thread Travis CI
Build Update for apache/httpd - Build: #818 Status: Still Failing Duration: 2 mins and 56 secs Commit: 2cec2d1 (trunk) Author: Stefan Eissing Message: *) mod_http2: workaround to facilitate use of common internal protocol/method/uri checks. The module

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Ruediger Pluem
On 6/17/20 11:52 AM, Yann Ylavic wrote: > On Wed, Jun 17, 2020 at 10:43 AM Joe Orton wrote: >> >>> And yes this makes me think if this kind of fake really makes sense. The >>> need to reset 3 request_rec fields after >>> ap_parse_request_line doesn't sound good. > > At this point it isn't an

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Stefan Eissing
I just read ap_parse_request_line() again. It seems to consist of 2 parts: 1. the parsing of the text line into protocol/method/uri bits with error checks 2. the check on method/uri correctness in combination with some protocol version specific checks I think the 2nd part is vital to run for

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Ruediger Pluem
On 6/17/20 10:43 AM, Joe Orton wrote: > On Tue, Jun 16, 2020 at 12:08:41PM +0200, Ruediger Pluem wrote: >> >> >> On 6/16/20 9:29 AM, Stefan Eissing wrote: Am 15.06.2020 um 21:46 schrieb Ruediger Pluem : I would like to unblock the test failure on trunk soon. Any comments on

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

2020-06-17 Thread Yann Ylavic
On Sat, Jun 13, 2020 at 11:18 AM jean-frederic clere wrote: > > On 11/06/2020 13:50, Yann Ylavic wrote: > > On Thu, Jun 11, 2020 at 1:22 PM Yann Ylavic wrote: > >> > >> On Thu, Jun 11, 2020 at 9:57 AM Yann Ylavic wrote: > >>> > >>> On Thu, Jun 11, 2020 at 9:50 AM Yann Ylavic wrote: > >

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Yann Ylavic
On Wed, Jun 17, 2020 at 10:43 AM Joe Orton wrote: > > > And yes this makes me think if this kind of fake really makes sense. The > > need to reset 3 request_rec fields after > > ap_parse_request_line doesn't sound good. At this point it isn't an HTTP/2 request IMHO, it's an HTTP/1 request

Re: Broken: apache/httpd#804 (trunk - 97bc128)

2020-06-17 Thread Joe Orton
On Tue, Jun 16, 2020 at 12:08:41PM +0200, Ruediger Pluem wrote: > > > On 6/16/20 9:29 AM, Stefan Eissing wrote: > >> Am 15.06.2020 um 21:46 schrieb Ruediger Pluem : > >> > >> I would like to unblock the test failure on trunk soon. Any comments on > >> the below? > > > > I am not really

Re: mod_proxy_fcgi bug using CONTENT_LENGTH and Transfer-Encoding chunked

2020-06-17 Thread Ruediger Pluem
On 6/16/20 11:57 PM, Oliver Dunk wrote: > Hi, > > I wanted to politely ask if anyone could take a look at  > https://bz.apache.org/bugzilla/show_bug.cgi?id=57087. This is an issue > where CONTENT_LENGTH isn’t forwarded correctly when using Transfer-Encoding > chunked. I feel uncomfortable