RE: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[BUSH Steve]

>> Maybe we can slip an additional entry into the changelog.
>> I think in this case, for now at least, we'd primarily rely on the error_log 
>> entry. Did this produce the new AH10410?

Yes, the error log did include the AH10410 message.

URL encoding the spaces either as \%20 (path or query string) or + (query 
string) does eliminate the problem for our mappings.

From: Eric Covener 
Sent: Wednesday, March 8, 2023 8:31 PM
To: dev@httpd.apache.org
Subject: Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

On Wed, Mar 8, 2023 at 11: 02 PM BUSH Steve  wrote: 
Correction! I used our test template for the rule when I e-mailed just now, but 
once it is converted to the apache httpd. conf format, the actual rule appears 
in the
ZjQcmQR
YFpfptBannerEnd

On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve 
mailto:steven.b...@3ds.com>> wrote:
Correction!
I used our test template for the rule when I e-mailed just now, but once it is 
converted to the apache httpd.conf format, the actual rule appears in the 
httpd.conf as:
RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of 
Records=$1&__poolid=animal-magic" [B,PT,L,QSA]

Thanks for the report.   Time will tell, but I think this is a very fringe 
case. The space isn't a backreference (where `B` would have fixed it) and a 
literal with a space in the substitution has to be quite rare (famous last 
words)
I just looked at the mod_rewrite.c source differences from 2.4.55 to 2.4.56 and 
it’s clear that the use of spaces in the query string of the mapped URL are the 
cause of the 403 forbidden messages.

We can update our httpd.conf mapping code, so it won’t be a problem for us, but 
it might be worth updating the mod_rewrite documentation on this?


Maybe we can slip an additional entry into the changelog.
I think in this case, for now at least, we'd primarily rely on the error_log 
entry. Did this produce the new AH10410?



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

mod_log_json

[Thomas Meyer]

Hi,

Today I did stumble upon mod_log_json in trunk, sadly it's not available in 
2.4.x.

This json loggers would be really helpful in k8s deployments.

Can this module get please get back ported to 2.4.

Are there any reasons that speak against it? Security concerns?

Mfg
Thomas

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Frank Gingras]

Or use [B], while being aware of the drawbacks.

On Thu, Mar 9, 2023 at 2:38 PM Fossies Administrator <
jens.schleuse...@fossies.org> wrote:

> On Thu, 9 Mar 2023, Eric Covener wrote:
>
> > On Thu, Mar 9, 2023 at 12:14 PM  wrote:
> >>
> >> On 3/9/23 05:30, Eric Covener wrote:
> >>>
> >>>
> >>> On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve  > wrote:
> >>>
> >>> Correction!
> >>>
> >>> I used our test template for the rule when I e-mailed just now,
> but once it is converted to the apache httpd.conf format, the actual rule
> appears in the httpd.conf as:
> >>>
> >>> RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number
> of Records=$1&__poolid=animal-magic" [B,PT,L,QSA]
> >>>
> >>>
> >>> Thanks for the report.   Time will tell, but I think this is a very
> fringe case. The space isn't a backreference (where `B` would have fixed
> it) and a literal with a space in the substitution has to be quite rare
> (famous last words)
> >>
> >> I wonder how many websites might have a snippet similar to:
> >>
> >> RewriteRule ^/search/(.*)$ /search.php?term=$1 [PT,L,QSA]
> >
> > I do worry about this style a lot more, especially with how much of a
> > pain [B] has been for me in the past.
> > I think we can wait and see and only look for more problematic
> > characters in the mod_rewrite.c change.
>
> I use a bit historically a rule principally like
>
>   RewriteRule file_name_pattern cgi_app?$1/$2 [T=application/x-httpd-cgi,L]
>
> With httpd-2.4.56 now all requests using file names containing a space are
> blocked (403 Forbidden) with the according error log entry
>
>   AH10410: Rewritten query string contains control characters or spaces
>
> The called CGI application tries to handle "bad" characters itself so from
> my egoistic point of view at least spaces should be allowed here (may be
> by an extra directive).
>
> In my case, the only but unsatisfactory workaround I have found so far
> would be to replace the affected spaces with %2520.
>
> Jens

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Fossies Administrator]

On Thu, 9 Mar 2023, Eric Covener wrote:


On Thu, Mar 9, 2023 at 12:14 PM  wrote:


On 3/9/23 05:30, Eric Covener wrote:



On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve mailto:steven.b...@3ds.com>> wrote:

Correction!

I used our test template for the rule when I e-mailed just now, but once it 
is converted to the apache httpd.conf format, the actual rule appears in the 
httpd.conf as:

RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of 
Records=$1&__poolid=animal-magic" [B,PT,L,QSA]


Thanks for the report.   Time will tell, but I think this is a very fringe 
case. The space isn't a backreference (where `B` would have fixed it) and a 
literal with a space in the substitution has to be quite rare (famous last 
words)


I wonder how many websites might have a snippet similar to:

RewriteRule ^/search/(.*)$ /search.php?term=$1 [PT,L,QSA]


I do worry about this style a lot more, especially with how much of a
pain [B] has been for me in the past.
I think we can wait and see and only look for more problematic
characters in the mod_rewrite.c change.


I use a bit historically a rule principally like

 RewriteRule file_name_pattern cgi_app?$1/$2 [T=application/x-httpd-cgi,L]

With httpd-2.4.56 now all requests using file names containing a space are 
blocked (403 Forbidden) with the according error log entry


 AH10410: Rewritten query string contains control characters or spaces

The called CGI application tries to handle "bad" characters itself so from 
my egoistic point of view at least spaces should be allowed here (may be 
by an extra directive).


In my case, the only but unsatisfactory workaround I have found so far 
would be to replace the affected spaces with %2520.


Jens

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Eric Covener]

On Thu, Mar 9, 2023 at 12:14 PM  wrote:
>
> On 3/9/23 05:30, Eric Covener wrote:
> >
> >
> > On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve  > > wrote:
> >
> > Correction!
> >
> > I used our test template for the rule when I e-mailed just now, but 
> > once it is converted to the apache httpd.conf format, the actual rule 
> > appears in the httpd.conf as:
> >
> > RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of 
> > Records=$1&__poolid=animal-magic" [B,PT,L,QSA]
> >
> >
> > Thanks for the report.   Time will tell, but I think this is a very fringe 
> > case. The space isn't a backreference (where `B` would have fixed it) and a 
> > literal with a space in the substitution has to be quite rare (famous last 
> > words)
>
> I wonder how many websites might have a snippet similar to:
>
> RewriteRule ^/search/(.*)$ /search.php?term=$1 [PT,L,QSA]

I do worry about this style a lot more, especially with how much of a
pain [B] has been for me in the past.
I think we can wait and see and only look for more problematic
characters in the mod_rewrite.c change.

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[giovanni]

On 3/9/23 05:30, Eric Covener wrote:



On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve mailto:steven.b...@3ds.com>> wrote:

Correction!

I used our test template for the rule when I e-mailed just now, but once it 
is converted to the apache httpd.conf format, the actual rule appears in the 
httpd.conf as:

RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of 
Records=$1&__poolid=animal-magic" [B,PT,L,QSA]


Thanks for the report.   Time will tell, but I think this is a very fringe 
case. The space isn't a backreference (where `B` would have fixed it) and a 
literal with a space in the substitution has to be quite rare (famous last 
words)


I wonder how many websites might have a snippet similar to:

RewriteRule ^/search/(.*)$ /search.php?term=$1 [PT,L,QSA]

  Giovanni




I just looked at the mod_rewrite.c source differences from 2.4.55 to 2.4.56 
and it’s clear that the use of spaces in the query string of the mapped URL are 
the cause of the 403 forbidden messages.

__ __

We can update our httpd.conf mapping code, so it won’t be a problem for us, 
but it might be worth updating the mod_rewrite documentation on this?



Maybe we can slip an additional entry into the changelog.
I think in this case, for now at least, we'd primarily rely on the error_log 
entry. Did this produce the new AH10410?






OpenPGP_signature
Description: OpenPGP digital signature

Re: mod_wasm: Contributing Upstream to Apache

[Jesús González]

Hola!

We just released a mod_wasm security update 
(v0.10.3) to 
address two recently disclosed CVEs (one critical) of Wasmtime, the WebAssembly 
runtime mod_wasm uses.

Further details can be found in this 
article and in 
the mod_wasm 
changelog.

Let us know if you find any issues.

Cheers!
Jesús

Re: Current pytest failures

[Rainer Jung]

Am 09.03.23 um 11:29 schrieb Stefan Eissing via dev:




Am 09.03.2023 um 11:22 schrieb Rainer Jung :

Puzzle partially solved: once I add "--header 'content-type: 
application/x-www-form-urlencoded'" to the nghttp call, the problem seems fixed - 
with and without deflate. No more hang, no more status 500, no double requests. I still 
don't know, which side is influenced, nghttp or http, so I am still not sure, whether the 
odd behavior without the header is a bug.


Hmm, never seen that. Is this a current nghttp? Normally, calling "nghttp 
--data=file" will do all that.

I think, since it stabilizes the test, please add the forced content-type 
header to the test suite. It should do no harm (famous last words),


Will do. It happens with nghttp 1.34.0 and recent 1.52.0. I took the 
header from my curl, which automatically adds it, but I think the right 
header is


Content-Type: multipart/form-data; boundary=DSAJKcd9876

That one is explicitly added in pyhttpd/nghttp.py in function 
upload_file, but not in post_name.


Skimming through the code for nghttp, it seems it dows add 
content-length (if not forbidden by a commandline flag), but I didn't 
find an explicit mentioning of content-type.


Best regards,

Rainer

Re: Current pytest failures

[Stefan Eissing via dev]

> Am 09.03.2023 um 11:22 schrieb Rainer Jung :
> 
> Puzzle partially solved: once I add "--header 'content-type: 
> application/x-www-form-urlencoded'" to the nghttp call, the problem seems 
> fixed - with and without deflate. No more hang, no more status 500, no double 
> requests. I still don't know, which side is influenced, nghttp or http, so I 
> am still not sure, whether the odd behavior without the header is a bug.

Hmm, never seen that. Is this a current nghttp? Normally, calling "nghttp 
--data=file" will do all that.

I think, since it stabilizes the test, please add the forced content-type 
header to the test suite. It should do no harm (famous last words),

- Stefan

> 
> Am 09.03.23 um 11:03 schrieb Rainer Jung:
>> OK, I can test in a standalone situation now.
>> The problem goes away, once I use curl, even with h2.
>> The problem also goes away, once I disable deflate compression for the 
>> response. But curl and nghttp behave different: nghttp hangs after receiving 
>> the response body (no deflate), curl normally terminates. nghttp does not 
>> hang if I call some normal production site.
>> Will investigate further.
>> Thanks and regards,
>> Rainer

Re: Current pytest failures

[Rainer Jung]

Puzzle partially solved: once I add "--header 'content-type: 
application/x-www-form-urlencoded'" to the nghttp call, the problem 
seems fixed - with and without deflate. No more hang, no more status 
500, no double requests. I still don't know, which side is influenced, 
nghttp or http, so I am still not sure, whether the odd behavior without 
the header is a bug.


Am 09.03.23 um 11:03 schrieb Rainer Jung:

OK, I can test in a standalone situation now.

The problem goes away, once I use curl, even with h2.

The problem also goes away, once I disable deflate compression for the 
response. But curl and nghttp behave different: nghttp hangs after 
receiving the response body (no deflate), curl normally terminates. 
nghttp does not hang if I call some normal production site.


Will investigate further.

Thanks and regards,

Rainer

Re: Current pytest failures

[Rainer Jung]

OK, I can test in a standalone situation now.

The problem goes away, once I use curl, even with h2.

The problem also goes away, once I disable deflate compression for the 
response. But curl and nghttp behave different: nghttp hangs after 
receiving the response body (no deflate), curl normally terminates. 
nghttp does not hang if I call some normal production site.


Will investigate further.

Thanks and regards,

Rainer

Re: Current pytest failures

[Rainer Jung]

I will see how to extract the test case out of pytest to be able to run 
it standalone and vary the protocol. But the connection reset plus 
second request might also be nghttp specific. I will also try running 
nghttp from remote and sniff to double check the connection reset plus 
second request.


Thanks and  regards,

Rainer

Am 09.03.23 um 09:19 schrieb Ruediger Pluem:



On 3/8/23 10:44 PM, Rainer Jung wrote:

Hi there,

I currently get three consistent pytest failures:


Do A) and B) work if you do the requests via HTTP/1.1?

Regards

Rüdiger

Re: Current pytest failures

[Rainer Jung]

Thanks for the tip. I already did the "run only one test case" and I 
fixed the LogLevel in test.conf to include trace8. So I guess there will 
not be any additional CGI logging available. But good to know the "-vvv".


Thanks and regards,

Rainer

Am 09.03.23 um 09:33 schrieb Stefan Eissing via dev:

One tip, if you call "pytest -vvv -k test_h2_202_03b", it will run just that test and 
raise LogLevel for several "interesting" modules.

The error log in test/gen/apache/logs/error_log will then show just that one 
test case. It's a convenient way to get more information without meddling with 
the test case configs.

The list of modules for which the log level is raised on "-vvv" is found in 
test/modules/http2/env.py:73

self.add_httpd_log_modules(["http2", "proxy_http2", "h2test", "proxy", 
"proxy_http"])

we can add "cgi" or others if those are of interest.

Re: Current pytest failures

[Stefan Eissing via dev]

One tip, if you call "pytest -vvv -k test_h2_202_03b", it will run just that 
test and raise LogLevel for several "interesting" modules.

The error log in test/gen/apache/logs/error_log will then show just that one 
test case. It's a convenient way to get more information without meddling with 
the test case configs.

The list of modules for which the log level is raised on "-vvv" is found in 
test/modules/http2/env.py:73

self.add_httpd_log_modules(["http2", "proxy_http2", "h2test", "proxy", 
"proxy_http"])

we can add "cgi" or others if those are of interest.

> Am 08.03.2023 um 22:44 schrieb Rainer Jung :
> 
> Hi there,
> 
> I currently get three consistent pytest failures:
> 
> 
> A) FAILED modules/http2/test_202_trailer.py::TestTrailers::test_h2_202_03b
> 
> Response code is 500 and trace 8 server log shows:
> 
> - we see the right request
> 
> [Wed Mar 08 22:03:35.699234 2023] [aptest:info] [pid 4606:tid 
> 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST 
> //echohd.py?name=X HTTP/2.0
> [Wed Mar 08 22:03:35.699247 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(436): [remote 127.0.0.1:50490] Headers 
> received from client:
> [Wed Mar 08 22:03:35.699254 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   Accept: */*
> [Wed Mar 08 22:03:35.699259 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] 
> Accept-Encoding: gzip, deflate
> [Wed Mar 08 22:03:35.699264 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] User-Agent: 
> nghttp2/1.52.0
> [Wed Mar 08 22:03:35.699268 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] 
> Content-Length: 119
> [Wed Mar 08 22:03:35.699273 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   Host: 
> 127.0.0.1:5001
> [Wed Mar 08 22:03:35.699277 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Ap-Test-Name: 
> test_h2_202_03b
> [Wed Mar 08 22:03:35.699282 2023] [http:trace4] [pid 4606:tid 
> 140645737559808] http_request.c(440): [remote 127.0.0.1:50490]   X: 3b
> 
> [Wed Mar 08 22:03:35.699425 2023] [authz_core:debug] [pid 4606:tid 
> 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: 
> authorization result of Require all granted: granted
> [Wed Mar 08 22:03:35.699440 2023] [authz_core:debug] [pid 4606:tid 
> 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: 
> authorization result of : granted
> [Wed Mar 08 22:03:35.699446 2023] [core:trace3] [pid 4606:tid 
> 140645737559808] request.c(362): [remote 127.0.0.1:50490] request authorized 
> without authentication by access_checker_ex hook: /echohd.py
> 
> We get the right response from the python CGI script:
> 
> [Wed Mar 08 22:03:35.784148 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(576): [remote 127.0.0.1:50490] Headers from 
> script 'echohd.py':
> [Wed Mar 08 22:03:35.784206 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(577): [remote 127.0.0.1:50490]   Status: 200
> [Wed Mar 08 22:03:35.784219 2023] [cgid:trace1] [pid 4606:tid 
> 140645737559808] util_script.c(658): [remote 127.0.0.1:50490] Status line 
> from script 'echohd.py': 200
> [Wed Mar 08 22:03:35.784234 2023] [cgid:trace4] [pid 4606:tid 
> 140645737559808] util_script.c(577): [remote 127.0.0.1:50490] Content-Type: 
> text/plain
> [Wed Mar 08 22:03:35.784255 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(169): [remote 127.0.0.1:50490] Content-Type 
> 'text/plain' ...
> [Wed Mar 08 22:03:35.784268 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(181): [remote 127.0.0.1:50490] ... did not 
> match 'text/html'
> [Wed Mar 08 22:03:35.784278 2023] [filter:trace4] [pid 4606:tid 
> 140645737559808] mod_filter.c(175): [remote 127.0.0.1:50490] ... matched 
> 'text/plain'
> 
> deflate compression wants to kick in (no idea whether that's part of the 
> problem)
> 
> [Wed Mar 08 22:03:35.784288 2023] [filter:trace2] [pid 4606:tid 
> 140645737559808] mod_filter.c(188): [remote 127.0.0.1:50490] Content-Type 
> condition for 'deflate' matched
> 
> and now a connection reset!
> 
> [Wed Mar 08 22:03:35.788364 2023] [cgid:trace1] [pid 4606:tid 
> 140645737559808] mod_cgid.c(1686): (104)Connection reset by peer: [remote 
> 127.0.0.1:50490] Failed to flush CGI output to client
> 
> and another request for that URL comes in:
> 
> [Wed Mar 08 22:03:35.788486 2023] [ssl:debug] [pid 4606:tid 140645737559808] 
> ssl_engine_kernel.c(422): [remote 127.0.0.1:50490] AH02034: Subsequent (No.2) 
> HTTPS request received for child 0 (server cgi.tests.httpd.apache.org:443)
> [Wed Mar 08 22:03:35.788500 2023] [aptest:info] [pid 4606:tid 
> 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST 
> 

Re: Current pytest failures

[Ruediger Pluem]

On 3/8/23 10:44 PM, Rainer Jung wrote:
> Hi there,
> 
> I currently get three consistent pytest failures:

Do A) and B) work if you do the requests via HTTP/1.1?

Regards

Rüdiger

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Stefan Eissing via dev]

> Am 08.03.2023 um 23:38 schrieb Eric Covener :
> 
> On Wed, Mar 8, 2023 at 4:57 PM BUSH Steve  wrote:
> 
>> Please remember to send the release announcement to annou...@httpd.apache.org
> 
> Maybe a moderation issue? Can anyone with the proper hat help check it
> out please?

In the releases I did, announce@ did *always* show delayed/lost processing of 
messages. It's not one of infras better services...