[Bug 69432] New: regression in mod rewrite rule while migrating from 2.4.59 to 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69432
Bug ID: 69432
Summary: regression in mod rewrite rule while migrating from
2.4.59 to 2.4.62
Product: Apache httpd-2
Version: 2.4.62
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: mod_rewrite
Assignee: bugs@httpd.apache.org
Reporter: rarath...@ptc.com
Target Milestone: ---
We are using below host header validation rule in Apache Http configuration,
that was working fine with 2.4.59 Apache server, when we migrate to 2.4.62
below rule is not working. It will ignore the host name validation in the
header(modify the hostname using burp tool). Can you please suggest what wrong
we are doing?
RewriteEngine On
RewriteCond %{HTTP_HOST} !test.test.test.com:2280$ [NC]
RewriteRule ^(.*)$ [R=301,L]
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69432] regression in mod rewrite rule while migrating from 2.4.59 to 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69432 rajendra rathore changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #2 from rajendra rathore --- Hi Ruediger, we fixed host header injection vullnurability by applying this rule, it was worked perfectly with 2.4.59 Apache Http server, it was stop working with latest Apache version, I enable loggers but not properly understand what is the issue here. [Wed Nov 06 18:33:26.123164 2024] [rewrite:trace2] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] init rewrite engine with requested uri /TEST123/app/, referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123233 2024] [rewrite:trace3] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] applying pattern '^(.*)$' to uri '/TEST123/app/', referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123243 2024] [rewrite:trace4] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] RewriteCond: input='vagrantq.ptcnet.ptc.com:2280' pattern='!^(test.test.com:2280)$' [NC] => matched, referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123244 2024] [rewrite:trace2] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] rewrite '/TEST123/app/' -> '[R=301,L]', referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123246 2024] [rewrite:trace3] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] add root prefix: [R=301,L] -> /[R=301,L], referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123248 2024] [rewrite:trace2] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] setting lastsub to rule with output [R=301,L], referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123249 2024] [rewrite:trace2] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] local path result: /[R=301,L], referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123253 2024] [rewrite:trace2] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] prefixed with document_root to /opt/ptc/raven_237/HTTPServer/htdocs/[R=301,L], referer: http://test.test.com:2280/TEST123/ [Wed Nov 06 18:33:26.123255 2024] [rewrite:trace1] [pid 2964750:tid 2964756] mod_rewrite.c(505): [client 172.27.192.1:57031] 172.27.192.1 - - [test.test.com/sid#e7d7b0][rid#7f7770002c10/initial] go-ahead with /opt/ptc/raven_237/HTTPServer/htdocs/[R=301,L] [OK], referer: http://test.test.com:2280/TEST123/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69432] regression in mod rewrite rule while migrating from 2.4.59 to 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69432 rajendra rathore changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #4 from rajendra rathore --- It was working fine with 2.4.59, pls let me know what is wrong here. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69432] regression in mod rewrite rule while migrating from 2.4.59 to 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69432 Ruediger Pluem changed: What|Removed |Added Status|NEW |NEEDINFO OS||All --- Comment #1 from Ruediger Pluem --- Please provide the log entries from the error log with log level trace8 for a request that does not behave as you expect how it behaves and what you expect it to behave. BTW: I have trouble to understand what RewriteRule ^(.*)$ [R=301,L] is expected to do as there is no second argument between the regular expression and the flags. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69432] regression in mod rewrite rule while migrating from 2.4.59 to 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69432 Eric Covener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Covener --- > RewriteRule ^(.*)$ [R=301,L] RewriteRule ^(.*)$ [R=301,L] The syntax is wrong. The flags are interpreted as the substitution parameter. Your 2nd parameter should be a URL if you are redirecting. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430
--- Comment #5 from Michael.R ---
still the same result in the response Content-Type Header: text/html...
< HTTP/1.1 400 Bad Request
< Date: Tue, 05 Nov 2024 13:07:35 GMT
< Server: Apache/2.4.62 (Unix) mod_wscmi/1.0 mod_token/1.0
< Content-Type: text/html; charset=iso-8859-1
<
{"foo": "bar"}
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430 --- Comment #4 from Yann Ylavic --- Hm, forget that, it still calls: ap_set_content_type_ex(r, "text/html...", 1); before. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430
--- Comment #3 from Yann Ylavic ---
And:
apr_table_unset(r->headers_out, "Content-Type");
ap_set_content_type(r, "text/json; charset=utf-8");
ap_custom_response(r, HTTP_BAD_REQUEST,
apr_pstrdup(r->pool, "\"{\"foo\": \"bar\"}"));
?
Note the new leading \" in the json, this is what's expected (and skipped) by
ap_send_error_response() to send plain text straight away.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430 --- Comment #2 from Michael.R --- Thanks for your answer, but that does not work because ap_set_content_type_ex(r, "text/html; charset=iso-8859-1", 1); in http_protocoll.c:1449 which finaly calls: ap_set_content_type(r, ct); overwrites it again. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430 --- Comment #1 from Yann Ylavic --- Possibly: apr_table_unset(r->headers_out, "Content-Type"); ap_set_content_type(r, "text/json; charset=utf-8"); would do? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430 Michael.R changed: What|Removed |Added CC||x...@freenet.de -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69430] New: ap_custom_response always overwrites an existing Content-Type Header set in r->headers_out
https://bz.apache.org/bugzilla/show_bug.cgi?id=69430
Bug ID: 69430
Summary: ap_custom_response always overwrites an existing
Content-Type Header set in r->headers_out
Product: Apache httpd-2
Version: 2.4.62
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Core
Assignee: bugs@httpd.apache.org
Reporter: x...@freenet.de
Target Milestone: ---
Hi,
i am working on a rest like client which returns json text. When i try to set
the Content-Type Header with:
ap_set_content_type( r, "text/json; charset=utf-8") ;
and sending the rsponse with:
ap_custom_response
(
r,
HTTP_BAD_REQUEST,
apr_pstrdup( r->pool, "{"foo": "bar"}" )
) ;
the Content-Type-Header always gets overwritten with: text/html;
charset=iso-8859-1
I have looked through the sources and found the function:
ap_send_error_response
in http_protocol.c which causes this behaviour.
When I surround the Line 1449 :
ap_set_content_type_ex(r, "text/html; charset=iso-8859-1", 1);
with an :
if ( ! apr_table_get(r->headers_out, "Content-Type") ) {
ap_set_content_type_ex(r, "text/html; charset=iso-8859-1", 1);
}
everything works fine. Do you think is's possibe to change this function, so
the Header can be set by the clients using the function: ap_custom_response
Regards
Michael
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69420] ProxyPassInherit should be independent from BalancerInherit
https://bz.apache.org/bugzilla/show_bug.cgi?id=69420 Jan changed: What|Removed |Added OS||All --- Comment #1 from Jan --- I found out that the current settings are displayed in the Balancer Manager. It seems that they are already independent. But the Documenation https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassinherit ist wrong. Can you confirm and fix the documentation? ProxyPassInherit On BalancerInherit On Balancer changes will NOT be persisted on restart. Balancers are inherited from main server. ProxyPass settings are inherited from main server. ProxyPassInherit Off BalancerInherit On Balancer changes will NOT be persisted on restart. Balancers are inherited from main server. ProxyPass settings are NOT inherited from main server. ProxyPassInherit On BalancerInherit Off Balancer changes will NOT be persisted on restart. Balancers are NOT inherited from main server. ProxyPass settings are inherited from main server. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69421] New: SSLVerifyClient require + TLS 1.3 = Cannot perform Post-Handshake Authentication
https://bz.apache.org/bugzilla/show_bug.cgi?id=69421 Bug ID: 69421 Summary: SSLVerifyClient require + TLS 1.3 = Cannot perform Post-Handshake Authentication Product: Apache httpd-2 Version: 2.4.62 Hardware: Macintosh Status: NEW Severity: normal Priority: P2 Component: mod_ssl Assignee: bugs@httpd.apache.org Reporter: rapha...@hotmail.fr Target Milestone: --- Hello, I just installed a fresh server, running debian 12 (comes with Apache 2.4.62), and I have a page protected with client certificate. 1- When I try to access the page using a browser (Safari on recent macOS) I have "You don't have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication." In log, the following error is logged: [Thu Oct 31 18:53:19.591300 2024] [ssl:error] [pid 2740:tid 2777] [client 83.202.xx.xx:62955] AH10158: cannot perform post-handshake authentication [Thu Oct 31 18:53:19.591499 2024] [ssl:error] [pid 2740:tid 2777] SSL Library Error: error:0A000117:SSL routines::extension not received I've also run tests using curl, it returns the same error until I use "--tls-max 1.2" arg to force 1.2. 2- I've also tried to disable TLS 1.3, on Apache side, to perform some tests, but the following directive didn't disable it "SSLProtocol -all +TLSv1.2 +TLSv1.1" Are those two behaviors normal? Thanks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69421] SSLVerifyClient require + TLS 1.3 = Cannot perform Post-Handshake Authentication
https://bz.apache.org/bugzilla/show_bug.cgi?id=69421 Raphael changed: What|Removed |Added OS||All -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69420] New: ProxyPassInherit should be independent from BalancerInherit
https://bz.apache.org/bugzilla/show_bug.cgi?id=69420 Bug ID: 69420 Summary: ProxyPassInherit should be independent from BalancerInherit Product: Apache httpd-2 Version: 2.4.51 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: mod_proxy Assignee: bugs@httpd.apache.org Reporter: jan.haer...@rz-kiru.de Target Milestone: --- In https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassinherit it is described, that BalancerInherit will be also disabled. Both parameters should be independent. ProxyPass configs are not listed in the Balancer Manager, so there is no issue why BalancerInherit is disabled too. UseCase 1: Activate global ProxyPass configs only in specific vhosts - main config ProxyPassInherit Off ProxyPass /test http://example.org/test ProxyPassReverse /test http://example.org/test - vhost ProxyPassInherit On UseCase 2: Use central Balancer Manager for all balancer - main config BalancerInherit On BalancerMember http://example.org BalancerMember http://example2.org - vhost ProxyPass /test balancer://example//test ProxyPassReverse balancer://example//test Because of https://bz.apache.org/bugzilla/show_bug.cgi?id=58120 this is actually not testable. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58120] ProxyPassInherit affects ProxyRemote, not ProxyPass
https://bz.apache.org/bugzilla/show_bug.cgi?id=58120 --- Comment #4 from Jan --- Will this issue be fixed in the near future? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 63186] Error pages aren't compressed (404, 410)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63186 Jan Willamowius changed: What|Removed |Added CC||j...@willamowius.de -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69414] New: sendfile() with TLS
https://bz.apache.org/bugzilla/show_bug.cgi?id=69414 Bug ID: 69414 Summary: sendfile() with TLS Product: Apache httpd-2 Version: 2.5-HEAD Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_ssl Assignee: bugs@httpd.apache.org Reporter: apache.ht...@proton.me Target Milestone: --- Since sendfile() isn’t available under TLS. I’m wondering if there’s plans for using openssl’s SSL_sendfile. Or is this more likely to be done through mod_tls via rustls’s ktls crate? In any case, I believe current docs relating to sendfile() (eg mod_cache_disk and tuning) need to be updated to reflect the fact that `EnableSendfile on` has no effect when TLS is used. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 63893] Bogus warning "unsupported command 20"
https://bz.apache.org/bugzilla/show_bug.cgi?id=63893 Bertrand Jacquin changed: What|Removed |Added CC||bertr...@jacquin.bzh -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62866] httpd do not correctly handle http request with proxy protocol LOCAL command ahead
https://bz.apache.org/bugzilla/show_bug.cgi?id=62866 Bertrand Jacquin changed: What|Removed |Added CC||bertr...@jacquin.bzh -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69412] mod_lua support for mod_session
https://bz.apache.org/bugzilla/show_bug.cgi?id=69412 --- Comment #1 from Christopher Head --- #61754 might be one possible way to do this, at least for reading, since a mod_lua script can execute an ap_expr, though a way to write to the session would still be useful. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69412] New: mod_lua support for mod_session
https://bz.apache.org/bugzilla/show_bug.cgi?id=69412 Bug ID: 69412 Summary: mod_lua support for mod_session Product: Apache httpd-2 Version: 2.5-HEAD Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: mod_lua Assignee: bugs@httpd.apache.org Reporter: ch...@chead.ca Target Milestone: --- It would be nice if mod_lua code could read and write mod_session data. Currently the only way I’ve found to do it is either (1) in a Lua handler, using `HTTP_SESSION` and the `SessionHeader` response header; or (2) in a fixups hook, for reading only, using `HTTP_SESSION`, by adding an additional custom-written module whose purpose is simply to order `mod_lua` after `mod_session` since they are both `APR_HOOK_MIDDLE` and don’t declare predecessors or successors (experimentation suggests that merely `LoadModule`ing `mod_session` first also works, but <https://httpd.apache.org/docs/2.4/developer/hooks.html#hooking-order> doesn’t mention that as an officially-sanctioned way to order hook execution, so I have to assume it’s undefined behaviour and could change in future versions). It would be nice if other hooks earlier than fixups could also access session data, and if session data could be accessed by a nicer API such as a table-like object like much of the other stuff accessible to mod_lua. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 61754] mod_session expression integration
https://bz.apache.org/bugzilla/show_bug.cgi?id=61754 Christopher Head changed: What|Removed |Added CC||ch...@chead.ca --- Comment #1 from Christopher Head --- Even if it only worked in some expression consumers, this would be nice! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65447] Reverse Proxy strange behaviour
https://bz.apache.org/bugzilla/show_bug.cgi?id=65447 Petr changed: What|Removed |Added OS||All --- Comment #1 from Petr --- I believe I encountered this issue as well. Turns out the proxied page didn't have any DocType set, and it seems browsers (Google Chrome, Firefox) use different User Agent Stylesheets based on the specified DocType. Setting the ProxyHTMLDocType directive to the same DocType as specified by the origin server solved this issue for me. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69404] htdbm poor user check leading to NullDereference
https://bz.apache.org/bugzilla/show_bug.cgi?id=69404 Artem Nasonov changed: What|Removed |Added Severity|normal |major -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69408] New: Modules Not Using ap_set_content_type_ex in Apache 2.4
https://bz.apache.org/bugzilla/show_bug.cgi?id=69408 Bug ID: 69408 Summary: Modules Not Using ap_set_content_type_ex in Apache 2.4 Product: Apache httpd-2 Version: 2.4.62 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: All Assignee: bugs@httpd.apache.org Reporter: tsyamam...@fujitsu.com Target Milestone: --- Hi Team, We plan to apply the following three fixes for the Apache 2.4 vulnerabilities CVE-2024-38476/CVE-2024-39884/CVE-2024-40725. However, it seems that some code might be missing fixes, and I am concerned about the completeness of these patches for Apache 2.4. - https://svn.apache.org/viewvc?view=revision&revision=1918560 - https://svn.apache.org/viewvc?view=revision&revision=1918839 - https://svn.apache.org/viewvc?view=revision&revision=1919249 I have a few questions: 1) The following fixes have been merged into the trunk. However, the same fixes have not been applied to the Apache 2.4 branch. Could you please let me know the reason why these fixes have not been applied to the Apache 2.4 branch? https://svn.apache.org/viewvc?view=revision&revision=1918823 https://svn.apache.org/viewvc?view=revision&revision=1918815 2) In the trunk, mod_proxy_balancer.c has been modified to use ap_set_content_type_ex in two places. https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c?r1=1918814&r2=1918813&pathrev=1918814 On the other hand, in the Apache 2.4 branch, only one place has been modified to use ap_set_content_type_ex, and the other place remains as ap_set_content_type. https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_balancer.c?r1=1918839&r2=1918838&pathrev=1918839 Is the remaining ap_set_content_type in the Apache 2.4 branch a mistake? 3) In mod_proxy_html.c in the trunk and the Apache 2.4 branch, both ap_set_content_type_ex and ap_set_content_type exist. https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_proxy_html.c?view=markup#l1022 https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_proxy_html.c?view=markup#l965 It sets "text/html;charset=" which is not treated as a handler name. Is the remaining ap_set_content_type a mistake? 4) In mod_cern_meta.c, the call to the ap_set_content_type method remains. https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_cern_meta.c?view=markup#l253 https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/metadata/mod_cern_meta.c?view=markup#l253 Therefore, it seems that the behavior changes when httpd.conf and meta files are configured as follows. httpd.conf LoadModule cern_meta_module "modules/mod_cern_meta.so" MetaFiles On MetaDir .meta MetaSuffix .meta /opt/apache/htdocs/.meta/hello.jpg.meta Content-Type: X Note: X is an invalid value that is not a typical MIME type. However, this configuration seems to be an unexpected use that is not documented. Is the reason for not fixing mod_cern_meta.c to prevent any arbitrary handler from being executed if such an unexpected meta file is created? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62161] no way to ensure error log contains timezone in timestamps
https://bz.apache.org/bugzilla/show_bug.cgi?id=62161
--- Comment #9 from Yann Ylavic ---
Yes it's available in 2.4.58 and later versions only (including trunk).
I have updated the docs for both trunk and 2.4.x, see
https://httpd.apache.org/docs/trunk/mod/core.html#errorlogformat for %{cuz}t
and %{%-format]t (the same should synchronize shortly in
https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat).
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62161] no way to ensure error log contains timezone in timestamps
https://bz.apache.org/bugzilla/show_bug.cgi?id=62161 --- Comment #8 from Christian Lange --- Thanks so much. Quick question: Did you only backport it to 2.4.58? Is there any chance of mentioning it in the docs, so others now about the possibility to include timezones? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69404] New: htdbm poor user check leading to NullDereference
https://bz.apache.org/bugzilla/show_bug.cgi?id=69404 Bug ID: 69404 Summary: htdbm poor user check leading to NullDereference Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: support Assignee: bugs@httpd.apache.org Reporter: anaso...@astralinux.ru Target Milestone: --- Created attachment 39912 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39912&action=edit htdbm failure test cases with stack traces htdbm sagfaults with specific parametrs. Steps to reproduce: 1. Built with: $ export CC="clang-17" $ export CXX="clang++-17" $ export CFLAGS="-pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address,undefined" $ export UBSAN_OPTIONS=print_stacktrace=1 $ svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr $ $ ./configure --with-included-apr --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-layout=Debian --enable-so --with-program-name=apache2 --enable-suexec --with-suexec-caller=www-data --with-suexec-bin=/usr/lib/apache2/suexec --with-suexec-docroot=/var/www --with-suexec-userdir=public_html --with-suexec-logfile=/var/log/apache2/suexec.log --with-suexec-uidmin=100 --enable-suexec=shared --enable-log-config=static --with-pcre=/usr/bin/pcre2-config --enable-pie --enable-mpms-shared=all --with-mpm=prefork --enable-mods-shared="all brotli cgi ident authnz_fcgi imagemap cern_meta proxy_fdpass proxy_http2 bucketeer case_filter case_filter_in" --enable-mods-static="unixd logio watchdog version" $ make 2. Find all testcases in attachment (with stacktraces). Option -l sets variable need_user = 0, since then we don't call htdbm_valid_username to check if we have a correct username in struct htdbm_t *h. This leads to NullDereference bugs in different functions. In my opinion, we should somehow patch this thing. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69344] rewrite rule issue with Apache 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69344 --- Comment #6 from Yann Ylavic --- Created attachment 39911 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39911&action=edit Add missing root/slash after whole ruleset processing only Wondering if we need something like this to keep configurations like here? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69344] rewrite rule issue with Apache 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69344
--- Comment #5 from Yann Ylavic ---
Each RewriteRule matches the current request path and (eventually) rewrites it
to a new request path for the next RewriteRule or further httpd processing.
Since 2.4.60, rewritten request pathes are forced to start with a slash if they
don't already, so your rules should look like this:
>RewriteMap lowercase int:tolower
>RewriteMap map-file
>txt:/prod/app/tv/dev_tv-launchpad_1.0.1_a/htdocs/maps/tv.dev.map
>
>RewriteRule ^/maps/ - [PT,L]
>
>RewriteCond %{REQUEST_URI} ^/tv/(.*)/? [NC]
>RewriteRule ^/ ${map-file:${lowercase:%1}|--state--}
>
>RewriteCond %{REQUEST_URI} ^/tv/((([^/]+)/)?.*)/? [NC]
>RewriteRule ^/--state-- ${map-file:${lowercase:%3}|--default--}
>
>RewriteCond %{REQUEST_URI} ^/(tv)/ [NC]
>RewriteRule ^/(.*) /--proto--/$1 [C]
>RewriteRule ^/(--proto--)/--default-- /$1/${map-file:default|--error--}
>
>RewriteRule ^/(--proto--)/(.*)([0-9]\.glb.wellsfargo.net)/?
>/$1/${map-file:${lowercase:$2}|$2}$3
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69344] rewrite rule issue with Apache 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69344
--- Comment #4 from Devendra ---
Hi Ruediger Pluem,
As suggested, we removed '/' from the beginning of the RewriteRule, but 2.4.62
version is still adding an additional '/' at the beginning of the URL and that
is failing.
it is adding a root prefix with 2.4.62 version. That is not the case with
2.4.59 even we have explicitly set '/' at the beginning of the rewrite rule.
Is there any way we can remove the root prefix with an additional rewriterule
or any other fix we can try. Please suggest.
Below are my Rewrite rules:
RewriteMap lowercase int:tolower
RewriteMap map-file
txt:/prod/app/tv/dev_tv-launchpad_1.0.1_a/htdocs/maps/tv.dev.map
RewriteRule ^/maps/-[PT,L]
#TEMPLATE?
RewriteCond %{REQUEST_URI} ^/tv/(.*)/?
[NC]
RewriteRule ^/ ${map-file:${lowercase:%1}|--state--}
#TEMPLATE?
# /svp/STATE/AU
RewriteCond %{REQUEST_URI} ^/tv/((([^/]+)/)?.*)/?
[NC]
RewriteRule ^--state-- ${map-file:${lowercase:%3}|--default--}
#TEMPLATE?
RewriteCond %{REQUEST_URI} ^/(tv)/ [NC]
RewriteRule ^(.*) --proto--$1
[C]
RewriteRule ^(--proto--)/--default--$1/${map-file:default|--error--}
#TEMPLATE?
#rewrite entire datacenter if in map eg, az-site1 ->sv-site1
RewriteRule ^(--proto--)/(.*)([0-9]\.glb.wellsfargo.net)/?
$1/${map-file:${lowercase:$2}|$2}$3
Log traces with version 2.4.62 as below.
init rewrite engine with requested uri /tv/qa2
applying pattern '^/maps/' to uri '/tv/qa2'
applying pattern '^/' to uri '/tv/qa2'
RewriteCond: input='/tv/qa2' pattern='^/tv/(.*)/?' [NC] => matched
map lookup OK: map=lowercase key=qa2 -> val=qa2
cache lookup FAILED, forcing new map lookup
map lookup OK: map=map-file[txt] key=qa2 -> val=tv-qa-wec-2-vip.hostname.com
rewrite '/tv/qa2' -> 'tv-qa-wec-2-vip.hostname.com'
add root prefix: tv-qa-wec-2-vip.hostname.com -> /tv-qa-wec-2-vip.hostname.com
setting lastsub to rule with output ${map-file:${lowercase:%1}|--state--}
applying pattern '^--state--' to uri '/tv-qa-wec-2-vip.hostname.com'
applying pattern '^(.*)' to uri '/tv-qa-wec-2-vip.hostname.com'
RewriteCond: input='/tv/qa2' pattern='^/(tv)/' [NC] => matched
rewrite '/tv-qa-wec-2-vip.hostname.com' ->
'--proto--/tv-qa-wec-2-vip.hostname.com'
add root prefix: --proto--/tv-qa-wec-2-vip.hostname.com ->
/--proto--/tv-qa-wec-2-vip.hostname.com
setting lastsub to rule with output --proto--$1
applying pattern '^(--proto--)/--default--' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^(--proto--)/(.*)([0-9]\\.glb.hostname.net)/?' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^--proto--/--error--' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^(--proto--/.*)--default--' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^(--proto--/.*)' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^--proto--/(https?://.*)' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^--proto--/(.*)' to uri
'/--proto--/tv-qa-wec-2-vip.hostname.com'
applying pattern '^/(.*)' to uri '/--proto--/tv-qa-wec-2-vip.hostname.com'
rewrite '/--proto--/tv-qa-wec-2-vip.hostname.com' -> '/launchpad.html'
setting lastsub to rule with output /launchpad.html
forcing '/launchpad.html' to get passed through to next API URI-to-filename
handler
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69402] New: mod_proxy_ajp ignores iobuffersize set in worker configuration
https://bz.apache.org/bugzilla/show_bug.cgi?id=69402 Bug ID: 69402 Summary: mod_proxy_ajp ignores iobuffersize set in worker configuration Product: Apache httpd-2 Version: 2.4.62 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_proxy_ajp Assignee: bugs@httpd.apache.org Reporter: j...@progress.com Target Milestone: --- According to documentation the iobuffersize parameter can be used to override ProxyIOBufferSize for a specific worker but mod_proxy_ajp ignores this setting and only uses what is set with ProxyIOBufferSize. With AJP it is important that both ends of the connection have the same buffer size to avoid errors and not all servers need this to be changed from default so it is desirable to be able to set this on individual workers. This patch against 2.4.62 code makes the parameter work as intended. --- mod_proxy_ajp.c.orig2023-11-18 06:08:42.0 -0500 +++ mod_proxy_ajp.c 2024-10-17 08:25:17.463355357 -0400 @@ -218,6 +218,9 @@ if (psf->io_buffer_size_set) maxsize = psf->io_buffer_size; +// Pick up buffer size set on individual worker +if (conn->worker->s->io_buffer_size_set) + maxsize = conn->worker->s->io_buffer_size; if (maxsize > AJP_MAX_BUFFER_SZ) maxsize = AJP_MAX_BUFFER_SZ; else if (maxsize < AJP_MSG_BUFFER_SZ) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65682] Apache won't start with mod_ssl and openssl 1.1.1l or newer
https://bz.apache.org/bugzilla/show_bug.cgi?id=65682 Joe Orton changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #8 from Joe Orton --- Upgrade to RHEL9. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #7 from edwardcrich...@hotmail.com --- # strings mod_ssl.so | egrep '^mod_ssl\/|^OpenSSL ' OpenSSL 1.1.1k FIPS 25 Mar 2021 mod_ssl/2.4.37 # rpm -q httpd httpd-2.4.37-65.module_el8.10.0+3874+c2064c23.2.x86_64 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69391] Personal data and restrictions based on subject directory attributes extension
https://bz.apache.org/bugzilla/show_bug.cgi?id=69391 Ruediger Pluem changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69390] Personal data and restrictions based on subject directory attributes extension
https://bz.apache.org/bugzilla/show_bug.cgi?id=69390 Ruediger Pluem changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #6 from Ruediger Pluem --- (In reply to Yann Ylavic from comment #5) > Maybe this is not working as expected because it's 2.4.37, while 2.4.42 > (r1873907) and later should work? Good catch with the version number. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #5 from Yann Ylavic --- Maybe this is not working as expected because it's 2.4.37, while 2.4.42 (r1873907) and later should work? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 Joe Orton changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #4 from Joe Orton --- Oh, I was reading the code totally wrong. Sorry. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #3 from Ruediger Pluem --- (In reply to Joe Orton from comment #1) > I'm not sure why it was implemented like that but it looks like it is always > global in scope. I think it should be disallowed within VirtualHost. Hm. The report above seems to indicate otherwise. It does not look global to me. ssl_find_vhost does an SSL_set_SSL_CTX using sc->server->ssl_ctx and this is where ssl_ctx_param sets the settings of SSLOpenSSLConfCmd via SSL_CONF_cmd. This seems to be virtual host specific. Isn't the issue that initially you end up in the default host and only after the SNI callback was executed you end up in the correct name based virtual host? What if the SSL protocol is set to none in the default virtualhost via SSLOpenSSLConfCmd ? Would that even prevent processing the SNI extensions provided by the client and thus switching to the virtualhost that allows more protocols? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 Joe Orton changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Joe Orton --- Fixed in trunk in r1921336. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 --- Comment #1 from Joe Orton --- I'm not sure why it was implemented like that but it looks like it is always global in scope. I think it should be disallowed within VirtualHost. I recommend you use mod_ssl's "native" config directives instead where possible. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69397] New: Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=69397 Bug ID: 69397 Summary: Effect of SSLOpenSSLConfCmd in catch-all VirtualHost affects other VirtualHosts Product: Apache httpd-2 Version: 2.4.37 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_ssl Assignee: bugs@httpd.apache.org Reporter: edwardcrich...@hotmail.com Target Milestone: --- Wanting to apply specific Groups, or Protocol to the catch-all using SSLOpenSSLConfCmd affects all other https connections on the web server. For example, if I deliberately wanted to make sure that TLS negotiation fails for the catch-all _default_:443 VirtualHost (or *:443) and yet works for those VirtualHosts that match a ServerName, I could try: # The first declaration that acts as a catch-all when no # other VirtualHost matches ServerName default.invalid Include /path/to/ssl/settings.conf.inc # Make sure there is a protocol in the list so the server starts up SSLProtocol +all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 +TLSv1.3 # Use the conf cmd to remove them all SSLOpenSSLConfCmd Protocol "-ALL" # and so on ... # A virtual host that can match on SNI ServerName my.virtual.host:443 # and so on... The server starts up. Now all requests to my.virtual.host are affected as well as requests to non-matched virtual hosts going to the catch-all. Accessing any site now reports: Firefox reports: Secure Connection Failed Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT Safari reports: can't establish a secure connection Chrome reports: This site can’t provide a secure connection my.virtual.host sent an invalid response. ERR_SSL_PROTOCOL_ERROR If the conf cmd SSLOpenSSLConfCmd Protocol "-ALL" is not put in the _default_:443 VirtualHost but rather is it put into the *:443 with the ServerName, the effect is as expected: only that VirtualHost is affected. This time, accessing my.virtual.host gives different results: Firefox: Peer reports incompatible or unsupported protocol version. Error code: SSL_ERROR_PROTOCOL_VERSION_ALERT Chrome: This site can’t provide a secure connection my.virtual.host uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH That result is what I hoped would happen but for the version that uses SSLOpenSSLConfCmd in the catch-all virtualhost . -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65222] LogFormat configuration directive is not properly merged
https://bz.apache.org/bugzilla/show_bug.cgi?id=65222 Michael Kaufmann changed: What|Removed |Added Keywords|PatchAvailable |FixedInTrunk -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 65222] LogFormat configuration directive is not properly merged
https://bz.apache.org/bugzilla/show_bug.cgi?id=65222 --- Comment #1 from Michael Kaufmann --- Pull Request: https://github.com/apache/httpd/pull/490 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69391] New: Personal data and restrictions based on subject directory attributes extension
https://bz.apache.org/bugzilla/show_bug.cgi?id=69391 Bug ID: 69391 Summary: Personal data and restrictions based on subject directory attributes extension Product: Apache httpd-test Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P2 Component: framework Assignee: bugs@httpd.apache.org Reporter: mohammadmasumshei...@gmail.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69390] New: Personal data and restrictions based on subject directory attributes extension
https://bz.apache.org/bugzilla/show_bug.cgi?id=69390 Bug ID: 69390 Summary: Personal data and restrictions based on subject directory attributes extension Product: Apache httpd-test Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P2 Component: framework Assignee: bugs@httpd.apache.org Reporter: mohammadmasumshei...@gmail.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62497] Make r.ap_auth_type writable
https://bz.apache.org/bugzilla/show_bug.cgi?id=62497 Michael Osipov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Michael Osipov --- Merged to trunk by Joe Orton. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #19 from Michael Osipov --- Apologies, I meant to share: https://jira.qos.ch/browse/LOGBACK-262 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #18 from Michael Osipov ---
For CustomLogFormat this works: "%{%FT%T}t.%{msec_frac}t", but not for ErrorLog
unfortunately :-( strftime(3) cannot format ms or µs
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #17 from Michael Osipov ---
(In reply to Yann Ylavic from comment #14)
> Created attachment 39905 [details]
> %{rfc3339*}t formats
>
> Patch from comment 13
Brief scanned through, my above comments apply and not that GMT is not the same
as UTC: https://www.fhs.swiss/eng/gmt-utc-tai.html
ISO 8601 uses UTC.
>From ISO 8601:2000
3.1:
> Coordinated Universal Time (UTC)
> time scale maintained by the Bureau international des poids et mesures
> (International Bureau of Weights and
> Measures) and the International Earth Rotation Service (IERS) which forms the
> basis of a coordinated
> dissemination of standard frequencies and time signals
>
> NOTE 2 UTC is often (incorrectly) referred to as Greenwich Mean Time
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #16 from Michael Osipov ---
(In reply to Yann Ylavic from comment #13)
> (In reply to Michael Osipov from comment #12)
> > Yann, there are actually several issues of you read my comments above. I
> > hesitated to open more issues since there was no traction here.
>
> So r1921259 changed the description of %{c}t to "The current time in ISO
> 8601 extended format (compact)", does it work for you?
Yes, this does.
> As for the "T' separator is missing", wikipedia says "Earlier versions
> omitted the T (representing time) in both formats", I think httpd is using
> such old version, and the docs talk about ISO 8601 for the time format
> alone, not the whole date string.
That statement is not correct. I have just opened ISO 8601:2000 through my
employer's portal and it says:
5.4.1:
> The character [T] shall be used as time designator to indicate the start of
> the representation of time of the day in date
> and time expressions. The hyphen [-] and the colon [:] shall be used, in
> accordance with 4.5, as separators within the
> date and time of the day expressions respectively, when required.
> NOTE By mutual agreement of the partners in information interchange, the
> character [T] may be omitted in applications
> where there is no risk of confusing a combined date and time of the day
> representation with others defined in this International
> Standard.
So, it has to be with "T" since there cannot be a mutual agreement with an
anonymous party. The same problem occured in git-log and that is why they
implemented 'iso8601-strict' for that. Similar bug in LogBack:
https://jira.qos.ch/browse/LOGBACK-1303
> Anyway I think it's too late to change the existing %{cuz}t format, we could
I agree that is it too late and it is actually broken another way:
> 2024-10-11 19:17:48.482240 +0200
The offset does not comply with ISO 8601:2000 since the space is not allowed
and all components need to be in the same format: extended or basic. Not mixed
(strftime's "%z" is not usable here). Ideally, you'd change the docs for
"cu"/"cuz" that they do not fully comply.
> add another another letter there to mean use ISO8601 / RFC3339 format for
> the whole date but at this point it's probably clearer to have:
> - %{rfc3339}t => -mm-ddThh:mm:ss+hh:mm
> - %{rfc3339_usec}t => -mm-ddThh:mm:ss.uu+hh:mm
> - %{rfc3339_utc}t => -mm-ddThh:mm:ssZ
> - %{rfc3339_utc_usec}t => -mm-ddThh:mm:ss.uuZ
> usable for both ErrorLogFormat and mod_log_config's CustomLog/LogFormat.
I'd agree with those, but I wouldn't even go through the indirection of RFC
3339, but straight to ISO 8601:
%{iso8601}t
%{iso8601_usec}t
%{iso8601_utc}t
%{iso860_usec_utc}t (intentionally) inverted because the TZ offset applies ot
the actual time, not the microseconds to UTC.
Also note that in the offsetted versions in the case the machine is in Etc/UTC
the printed offset must be "Z", not "+00:00". See also my report with Git:
https://lore.kernel.org/git/410d458c-ae5b-40cc-9c8e-97b016c74...@siemens.com/
Thank your for your time.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #15 from Yann Ylavic --- > Created attachment 39905 [details] Off by one in AP_TIME_RFC3339_MAX_LEN fixed already. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #14 from Yann Ylavic ---
Created attachment 39905
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39905&action=edit
%{rfc3339*}t formats
Patch from comment 13
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #13 from Yann Ylavic ---
(In reply to Michael Osipov from comment #12)
> Yann, there are actually several issues of you read my comments above. I
> hesitated to open more issues since there was no traction here.
So r1921259 changed the description of %{c}t to "The current time in ISO 8601
extended format (compact)", does it work for you?
As for the "T' separator is missing", wikipedia says "Earlier versions omitted
the T (representing time) in both formats", I think httpd is using such old
version, and the docs talk about ISO 8601 for the time format alone, not the
whole date string.
Anyway I think it's too late to change the existing %{cuz}t format, we could
add another another letter there to mean use ISO8601 / RFC3339 format for the
whole date but at this point it's probably clearer to have:
- %{rfc3339}t => -mm-ddThh:mm:ss+hh:mm
- %{rfc3339_usec}t => -mm-ddThh:mm:ss.uu+hh:mm
- %{rfc3339_utc}t => -mm-ddThh:mm:ssZ
- %{rfc3339_utc_usec}t => -mm-ddThh:mm:ss.uuZ
usable for both ErrorLogFormat and mod_log_config's CustomLog/LogFormat.
I'm attaching a patch (based on Alexandre's) which does that, let's see if we
can go with this.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #12 from Michael Osipov ---
(In reply to Yann Ylavic from comment #11)
> Hm, realizing that there is maybe no way to express an RFC3339 date with
> strftime() and that %{cuz}t does not match either, so reopening.
Yann, there are actually several issues of you read my comments above. I
hesitated to open more issues since there was no traction here.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
Yann Ylavic changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED|REOPENED
--- Comment #11 from Yann Ylavic ---
Hm, realizing that there is maybe no way to express an RFC3339 date with
strftime() and that %{cuz}t does not match either, so reopening.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62161] no way to ensure error log contains timezone in timestamps
https://bz.apache.org/bugzilla/show_bug.cgi?id=62161 Yann Ylavic changed: What|Removed |Added CC||lehm...@cnm.de --- Comment #7 from Yann Ylavic --- *** Bug 57339 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
Yann Ylavic changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #10 from Yann Ylavic ---
Since 2.4.58 (r1911079, see bug 62161) one can use %{z}t or a custom
%{}t (see
https://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html for
) to have a timezone in error log timestamps.
Unfortunately the documentation seems to be missing in
https://httpd.apache.org/docs/current/mod/core.html#errorlogformat, let me try
to put something there.
*** This bug has been marked as a duplicate of bug 62161 ***
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69383] segfault in ab started with wrong parametrs
https://bz.apache.org/bugzilla/show_bug.cgi?id=69383 Yann Ylavic changed: What|Removed |Added Keywords||FixedInTrunk Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Yann Ylavic --- Thanks, fixed in r1921256. I'm not sure it warrants a backport to 2.4.x (where -c0 seems to cause a crash too) since -c0 is not really supposed to be used.. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #9 from Alexandre Schaff --- Created attachment 39904 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39904&action=edit patchset without backup files Sorry for later patches. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #8 from Michael Osipov --- Comment on attachment 39903 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39903 correction to have patch Why is the patch so huge? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #7 from Alexandre Schaff --- Created attachment 39903 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39903&action=edit correction to have patch corrected -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #6 from Michael Osipov --- (In reply to Alexandre Schaff from comment #5) > Created attachment 39902 [details] > patch for utc > > Try this patch on 2.4.62 (not trunk). > > timestamp follows https://tools.ietf.org/html/rfc3339#section-5.6. > and https://datatracker.ietf.org/doc/html/rfc3339#section-5.3 > > Format is thus: > -mm-ddThh:mm:ss.uuZ > > %Z for both ErrorLogFormat and LogFormat. > > Timezone, if desired, can be added as a separate log entry. > From : https://www.manning.com/books/securing-devops : "Standardize the > timestamp format. (...) get your entire organization to adopt RFC3339 (...) > No one likes converting time zones when comparing logs." This isn't a patch, but a collection of files. Can you attached a patch in unified diff format? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 Alexandre Schaff changed: What|Removed |Added CC||alexandre.sch...@gmail.com --- Comment #5 from Alexandre Schaff --- Created attachment 39902 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39902&action=edit patch for utc Try this patch on 2.4.62 (not trunk). timestamp follows https://tools.ietf.org/html/rfc3339#section-5.6. and https://datatracker.ietf.org/doc/html/rfc3339#section-5.3 Format is thus: -mm-ddThh:mm:ss.uuZ %Z for both ErrorLogFormat and LogFormat. Timezone, if desired, can be added as a separate log entry. >From : https://www.manning.com/books/securing-devops : "Standardize the timestamp format. (...) get your entire organization to adopt RFC3339 (...) No one likes converting time zones when comparing logs." -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69203] proxy error from php-fpm backend for paths containing spaces
https://bz.apache.org/bugzilla/show_bug.cgi?id=69203 Yann Ylavic changed: What|Removed |Added Keywords||FixedInTrunk --- Comment #19 from Yann Ylavic --- The proposed changes for the next httpd release are in https://github.com/apache/httpd/pull/470 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #4 from Michael Osipov --- Yet another issue: The documentation says "The current time in compact ISO 8601 format, including micro-seconds". There is no compact ISO 8601 format. There is only basic and extended and ErrorLogFormat uses the extended only. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57339] ErrorLogFormat doesn't allow logging in Internet date/time format
https://bz.apache.org/bugzilla/show_bug.cgi?id=57339 --- Comment #3 from Michael Osipov --- Stubled over this again and even willing to provide a patch, but there seems no engagement from committer's side. As an ASF committer I have been waiting for years for my PRs to be reviewed: https://www.mail-archive.com/dev@httpd.apache.org/msg78258.html -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69383] New: segfault in ab started with wrong parametrs
https://bz.apache.org/bugzilla/show_bug.cgi?id=69383 Bug ID: 69383 Summary: segfault in ab started with wrong parametrs Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: support Assignee: bugs@httpd.apache.org Reporter: anaso...@astralinux.ru Target Milestone: --- Created attachment 39897 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39897&action=edit Stacktrace of error ab segfaults when call with -c0 parametr. Steps to Reproduce: Built with: $ export CC="clang-17" $ export CXX="clang++-17" $ export CFLAGS="-pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address,undefined" $ export UBSAN_OPTIONS=print_stacktrace=1 $ svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr $ $ ./configure --with-included-apr --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-layout=Debian --enable-so --with-program-name=apache2 --enable-suexec --with-suexec-caller=www-data --with-suexec-bin=/usr/lib/apache2/suexec --with-suexec-docroot=/var/www --with-suexec-userdir=public_html --with-suexec-logfile=/var/log/apache2/suexec.log --with-suexec-uidmin=100 --enable-suexec=shared --enable-log-config=static --with-pcre=/usr/bin/pcre2-config --enable-pie --enable-mpms-shared=all --with-mpm=prefork --enable-mods-shared="all brotli cgi ident authnz_fcgi imagemap cern_meta proxy_fdpass proxy_http2 bucketeer case_filter case_filter_in" --enable-mods-static="unixd logio watchdog version" $ make After that call $ ./support/ab -c0 0:9/ You can see result in the attachment. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69367] mod_cgi(d) does not support HTTP/2 server-sent events in full duplex mode
https://bz.apache.org/bugzilla/show_bug.cgi?id=69367 Joe Orton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Joe Orton --- IMO trying to contort the CGI specification, protocol and mod_cgi/d implementations to allow full-duplex request/response streaming is not in scope. None of it was designed to work like that, it would be better to switch to an existing spec/protocol/implementation which was - e.g. websockets, or exposing your application as an HTTP/2 server directly. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69378] New: RUSTLS issue
https://bz.apache.org/bugzilla/show_bug.cgi?id=69378 Bug ID: 69378 Summary: RUSTLS issue Product: Apache httpd-2 Version: 2.4.62 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P2 Component: Other Modules Assignee: bugs@httpd.apache.org Reporter: lakshmi_prasa...@hotmail.com Target Milestone: --- Wanted RUSTLS support for apache2.4.62 version. Downloaded RUSTLS from git (version 0.23.14) and apache2 configure script reports that rustls version >= 0.9.2 check failed. Though it is a old verison, I tried using rustls_ffi. This time configure script works fine but make fails reoporting issues with tls_core.c so on.. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 61081] per-domain SNI (to override per-vhost SNI)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61081 --- Comment #9 from Ashish Sabharwal --- Though I'm not sure if you'd want one directive with several arguments or distinct mapping directives for the certificate, key, and chain files, I believe a directive akin to IBM's SSLSNIMap would be excellent. I'm leaning toward the former because the latter would get very long. https://www.amitextanks.com/grp-panel-water-tanks.html -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69356] incorrect revocation order when relinquishing privileges
https://bz.apache.org/bugzilla/show_bug.cgi?id=69356
--- Comment #2 from Jeffrey Bencteux ---
Indeed the above code could be correct for restoring privileges. However I
found the instance of that issue where privileges are dropped in the same file:
173 static int privileges_req(request_rec *r)
174 {
175 /* secure mode: fork a process to handle the request */
...
251 /* OK, now drop privileges. */
252
253 /* cleanup should happen even if something fails part-way through
here */
254 apr_pool_cleanup_register(r->pool, r, privileges_end_req,
255 apr_pool_cleanup_null);
256 /* set user and group if configured */
257 if (cfg->uid || cfg->gid) {
258 if (setppriv(PRIV_ON, PRIV_EFFECTIVE, priv_setid) == -1) {
259 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02144)
260 "No privilege to set user/group");
261 }
262 /* if we should be able to set these but can't, it could be
263 * a serious security issue. Bail out rather than risk it!
264 */
265 if (cfg->uid && (setuid(cfg->uid) == -1)) {
266 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02145)
267 "Error setting userid");
268 return HTTP_INTERNAL_SERVER_ERROR;
269 }
270 if (cfg->gid && (setgid(cfg->gid) == -1)) {
271 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02146)
272 "Error setting group");
273 return HTTP_INTERNAL_SERVER_ERROR;
274 }
275 }
I believe this code is used to drop privileges in child process when
"PrivilegesMode SECURE" is used.
An attacker controlling code executed in the child process can do a subsequent
call to setgid() and regain privileges, making the SECURE mode ineffective.
I am attaching a new version of the patch to fix that section of the code.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69356] incorrect revocation order when relinquishing privileges
https://bz.apache.org/bugzilla/show_bug.cgi?id=69356 Jeffrey Bencteux changed: What|Removed |Added Attachment #39884|0 |1 is obsolete|| --- Comment #1 from Jeffrey Bencteux --- Created attachment 39896 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39896&action=edit Patch reordering set*id() calls v2 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 42605] HTTPS-URL with special-port requesting a directory (without trailing slash) is rewritten to HTTPS-URL requesting a directory with trailing slash, BUT the specified port is missing
https://bz.apache.org/bugzilla/show_bug.cgi?id=42605 Akshar herbs and Spices changed: What|Removed |Added CC||nisam.a...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 50210] error 404 on access the files in icons directory
https://bz.apache.org/bugzilla/show_bug.cgi?id=50210 --- Comment #3 from Justin --- The alias is a default in apache httpd. This caused meissues as well and really should just be removed, or not applied to user-created vhosts. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69344] rewrite rule issue with Apache 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69344 --- Comment #3 from Ruediger Pluem --- (In reply to Devendra from comment #2) > (In reply to Ruediger Pluem from comment #1) > > This is likely caused by the fix for CVE-2024-39573 in 2.4.60 and works as > > designed (see why on > > https://httpd.apache.org/security/vulnerabilities_24.html). Expect that the > > result of each RewriteRule with no Redirect or Proxy flags starts with a '/' > > even if the substitution string does not and adjust your RewriteRules to > > accommodate for this. > > > Thanks for response - Ruediger Pluem. > So, does it mean 2.4.60 and higher versions will add "/" to RewriteRule even > it is already present? It will only add one at the beginning if none is present and if it does not have a redirect or proxy flag. If one is present nothing will be added. > > We have log entry where an additional "/" was added and the application is > not working. > > Should we replace > > RewriteRule ^(.*) --proto--/$1 [C] > > with > > RewriteRule ^(.*) --proto--$1 [C] I did not look extensively at your rewriterules, but from a brief look I would expect that $1 always starts with a '/' in the rule above and hence you should remove it. Probably it is a good idea to modify your other rules above this rule to ensure that they always result in something that starts with a '/'. This would also ensure backwards compatibility with older HTTP Server versions. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69344] rewrite rule issue with Apache 2.4.62
https://bz.apache.org/bugzilla/show_bug.cgi?id=69344 --- Comment #2 from Devendra --- (In reply to Ruediger Pluem from comment #1) > This is likely caused by the fix for CVE-2024-39573 in 2.4.60 and works as > designed (see why on > https://httpd.apache.org/security/vulnerabilities_24.html). Expect that the > result of each RewriteRule with no Redirect or Proxy flags starts with a '/' > even if the substitution string does not and adjust your RewriteRules to > accommodate for this. Thanks for response - Ruediger Pluem. So, does it mean 2.4.60 and higher versions will add "/" to RewriteRule even it is already present? We have log entry where an additional "/" was added and the application is not working. Should we replace RewriteRule ^(.*) --proto--/$1 [C] with RewriteRule ^(.*) --proto--$1 [C] While testing we observed that with 2.4.62 the rewrite output is having an additional ‘/’ as highlighted below. Apart from that we don’t see any error in trace log. 2.4.62 (failing to error.html) [Mon Aug 19 14:14:47.360450 2024] [rewrite:trace4] [pid 1177:tid 11999] mod_rewrite.c(505): [client :] - - [cci-launchpad-dev.hostname.com/sid#700070][rid#7f4468002970/initial] RewriteCond: input='/tv/qa1' pattern='^/(tv)/' [NC] => matched [Mon Aug 19 14:14:47.360468 2024] [rewrite:trace2] [pid 1177:tid 11999] mod_rewrite.c(505): [client :] - - [cci-launchpad-dev.hostname.com/sid#700070][rid#7f4468002970/initial] rewrite '/tv-qa-stl-1-vip.hostname.com' -> '--proto--//tv-qa-stl-1-vip.hostname.com' vs 2.4.59 (Working as expected) [Fri Aug 16 13:10:17.778806 2024] [rewrite:trace4] [pid 7669:tid 139952923162048] mod_rewrite.c(493): [client :] - - [cci-launchpad-dev.hostname.com/sid#6fb2e0][rid#7f4934002970/initial] RewriteCond: input='/tv/qa1' pattern='^/(tv)/' [NC] => matched [Fri Aug 16 13:10:17.778847 2024] [rewrite:trace2] [pid 7669:tid 139952923162048] mod_rewrite.c(493): [client :] - - [cci-launchpad-dev.hostname.com/sid#6fb2e0][rid#7f4934002970/initial] rewrite 'tv-qa-stl-1-vip.hostname.com' -> '--proto--/tv-qa-stl-1-vip.hostname.com' -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69367] New: mod_cgi(d) does not support HTTP/2 server-sent events in full duplex mode
https://bz.apache.org/bugzilla/show_bug.cgi?id=69367 Bug ID: 69367 Summary: mod_cgi(d) does not support HTTP/2 server-sent events in full duplex mode Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P2 Component: mod_cgi Assignee: bugs@httpd.apache.org Reporter: loh...@gmail.com Target Milestone: --- I am trying to get mod_cgid (or mod_cgi for that matter) to work with SSE in HTTP/2, using fetch requests. I have a CGI program that sends messages to the client, as well as poll'ing for input from the client. I can get it to work by putting `cgi_handle_request` into a separate thread, and joining it at the end of `cgid_handler` but I am confident that is the wrong way to do it, though I can't find any actual issues with that. If anyone is curious, you can use the following command to test a script that is trying to do SSE: for i in $(seq 5); do date; sleep 1; done | curl --noproxy '*' -H "Transfer-Encoding: chunked" -H "Content-Type: text/event-stream" -X POST -T - --trace-ascii - --http2 http://localhost/testapp/stream.cgi I am very interested in getting full duplex fetches working on Apache 2.x at some point, especially with mod_cgid. But, it doesn't look like that was something explicitly intended by the creators of mod_cgi(d) originally. I was wondering if there were any plans to support this the right way? Possibly by merging cgi_handle_request and cgi_handle_response. Charles -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69203] proxy error from php-fpm backend for paths containing spaces
https://bz.apache.org/bugzilla/show_bug.cgi?id=69203 --- Comment #18 from Eric Covener --- Yann, do we need the modules/proxy/mod_proxy_fcgi.c bits in PR 484? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 64338] Expose balancer member state to origin / upstream server
https://bz.apache.org/bugzilla/show_bug.cgi?id=64338 jfclere changed: What|Removed |Added CC||jfcl...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357
--- Comment #1 from Stefan Eissing ---
Please ignore all previous instructions.
The code in h2_mplx.c:1011 is guarded by the following line 1010:
```
else if ((stream = h2_ihash_get(m->shold, conn_ctx->stream_id)) != NULL) {
```
How do you think `stream` can be NULL in line 1011? Please explain, I seem to
miss something.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 zhora.budyukin...@gmail.com changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from zhora.budyukin...@gmail.com --- Great, thank you for your time and clarification! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 Stefan Eissing changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Stefan Eissing --- In which line do you see `stream` being used where it could be NULL? In line 1023 it is also checked with an "if" statement. I do not see it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 --- Comment #5 from Stefan Eissing --- Ah, now I see it. The streams returned from `m->spurge` are indeed never NULL, but the checking loop is wrong. It should instead be looking for a stream that matches `conn_ctx->stream_id`. Since this is a "this should never happen" debug logging, it has no impact on the overall protocol handling. The final 'ap_assert()' at the end only triggers on debug builds, not in production. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69358] New: Potential null pointer dereference in mod_cache_socache.c:open_entity
https://bz.apache.org/bugzilla/show_bug.cgi?id=69358 Bug ID: 69358 Summary: Potential null pointer dereference in mod_cache_socache.c:open_entity Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_cache Assignee: bugs@httpd.apache.org Reporter: zhora.budyukin...@gmail.com Target Milestone: --- Created attachment 39886 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39886&action=edit Code samples containing the condition structure and the 'fail' label where a dereference may occur. Null pointer is assigned to 'nkey' variable in line 462. If condition in line 529 is false and the following condition in line 588 is true, a jump to the 'fail' label is executed, skipping non-null assignments to 'nkey' in other conditional blocks. This way, it may be dereferenced in line 705. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 zhora.budyukin...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #4 from zhora.budyukin...@gmail.com --- I see now that I was assuming that APR_ARRAY_IDX function could return NULL at the same time as `stream`. If such possibility doesn't exist, then there should be no issue indeed. I apologize for my inattention. Could you please confirm if APR_ARRAY_IDX could return NULL here or not, just for me to be sure? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 zhora.budyukin...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #2 from zhora.budyukin...@gmail.com --- What I mean is, in case of this condition being false (therefore `stream` being NULL), we go to the `else` statement, after which stream is used in another condition and may be used in ap_log_cerror function. Please correct me if I'm missing something here. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 Stefan Eissing changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #7 from Stefan Eissing --- Thanks for reviewing and finding the mistake. I added the correction as r1921066 in Apache's trunk. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 Stefan Eissing changed: What|Removed |Added Status|NEW |NEEDINFO -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69358] Potential null pointer dereference in mod_cache_socache.c:open_entity
https://bz.apache.org/bugzilla/show_bug.cgi?id=69358 Ruediger Pluem changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Keywords||FixedInTrunk, ||PatchAvailable --- Comment #1 from Ruediger Pluem --- Thanks. Fixed in r1921067. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69203] proxy error from php-fpm backend for paths containing spaces
https://bz.apache.org/bugzilla/show_bug.cgi?id=69203 --- Comment #17 from v...@f-m.fm --- (In reply to Santiago Ruano Rincón from comment #16) > (In reply to Yann Ylavic from comment #13) > > The proposed patch is possibly not complete, I started a dev@ discussion > > here: https://lists.apache.org/thread/m3gckqpp9b30t26xgfjbnhtzm9166gsd > > Hello Yann, > > May I ask you if there has been any update on the patch? I can see update > proposal in the above mentioned link, but I am not sure if you have reached > any conclusion. > > TIA, > > -- Santiago +1 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69357] New: Possible null dereference in h2_mplx.c:s_c2_done
https://bz.apache.org/bugzilla/show_bug.cgi?id=69357 Bug ID: 69357 Summary: Possible null dereference in h2_mplx.c:s_c2_done Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_http2 Assignee: bugs@httpd.apache.org Reporter: zhora.budyukin...@gmail.com Target Milestone: --- Created attachment 39885 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39885&action=edit The sample from h2_mplx.c that contains a possible dereference. A condition in line 1011 of h2_mplx.c states that the 'stream' variable should not be NULL in order to enter the following block of code. Otherwise it enters the 'else' block and is used in ap_log_cerror function in line 1023, implying a null pointer dereference. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69356] New: incorrect revocation order when relinquishing privileges
https://bz.apache.org/bugzilla/show_bug.cgi?id=69356
Bug ID: 69356
Summary: incorrect revocation order when relinquishing
privileges
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: mod_privileges
Assignee: bugs@httpd.apache.org
Reporter: jeffbenct...@gmail.com
Target Milestone: ---
Created attachment 39884
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39884&action=edit
Patch reordering set*id() calls
I believe there are particular cases in which relinquishing of privileges in
function privileges_end_req() of file /modules/arch/unix/mod_privileges.c is
incorrect.
In particular, the setuid() (line 156) function is called before the setgid()
(line 160) one:
131 static apr_status_t privileges_end_req(void *data)
132 {
133 request_rec *r = data;
134 priv_cfg *cfg = ap_get_module_config(r->server->module_config,
135 &privileges_module);
136 priv_dir_cfg *dcfg = ap_get_module_config(r->per_dir_config,
137 &privileges_module);
138
139 /* ugly hack: grab default uid and gid from unixd */
140 extern unixd_config_rec ap_unixd_config;
141
142 /* If we forked a child, we dropped privilege to revert, so
143 * all we can do now is exit
144 */
145 if ((cfg->mode == PRIV_SECURE) ||
146 ((cfg->mode == PRIV_SELECTIVE) && (dcfg->mode == PRIV_SECURE)))
{
147 exit(0);
148 }
149
150 /* if either user or group are not the default, restore them */
151 if (cfg->uid || cfg->gid) {
152 if (setppriv(PRIV_ON, PRIV_EFFECTIVE, priv_setid) == -1) {
153 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02136)
154 "PRIV_ON failed restoring default
user/group");
155 }
156 if (cfg->uid && (setuid(ap_unixd_config.user_id) == -1)) {
157 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02137)
158 "Error restoring default userid");
159 }
160 if (cfg->gid && (setgid(ap_unixd_config.group_id) == -1)) {
161 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02138)
162 "Error restoring default group");
163 }
164 }
This results in setgid() call only changing the effective group ID to the
wanted one; the real group ID and saved set-group-ID remain unchanged.
That allow code executed afterwards to regain privileges with subsequents
setgid() calls.
This is explained in details in POSIX rules:
https://wiki.sei.cmu.edu/confluence/display/c/POS36-C.+Observe+correct+revocation+order+while+relinquishing+privileges
I doubt this is the intended behaviour for that function. I am attaching a
patch inverting the setuid() and setgid() calls to conform to the POSIX
privilege relinquishing order.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69345] ERR_HTTP2_PROTOCOL_ERROR
https://bz.apache.org/bugzilla/show_bug.cgi?id=69345 Stefan Eissing changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEEDINFO|RESOLVED --- Comment #15 from Stefan Eissing --- I'll mark this as closed for now. Please feel free to have me reopen it if you think this is an Apache bug. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69352] jmeter function RandomFromMultipleVars() run twice in a request
https://bz.apache.org/bugzilla/show_bug.cgi?id=69352 Ruediger Pluem changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED OS||All --- Comment #1 from Ruediger Pluem --- Jmeter issues need to be opened here: https://github.com/apache/jmeter/issues -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 69350] AH00051: child pid 3886730 exit signal Segmentation fault (11), possible coredump in /etc/httpd
https://bz.apache.org/bugzilla/show_bug.cgi?id=69350 Eric Covener changed: What|Removed |Added Resolution|--- |INVALID Status|NEEDINFO|RESOLVED --- Comment #3 from Eric Covener --- (In reply to Dave Wreski from comment #2) > This was indeed the cause. I've now removed mod_perl entirely, as we stopped > using it some time ago. Did you believe this was the cause because it is not > commonly used anymore? Usually there is a more obvious culprit in the gdb output. In this case, every other thread is in a "normal" blocking system call (including most being idle). It's also common for bugs to occur when running end-of-request cleanups if memory has been mismanaged and that's what mod_perl is doing here. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
