[Bug 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #12 from Yann Ylavic --- Also, I think that a backend should not allow itself to respond early and close the connection (without reading the whole request) unless 100-continue is involved somehow. HTTP being transactional, a proxy can legitimately (IMHO) respond with an error if it could not send the request completely.. -- 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 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #11 from Yann Ylavic --- (In reply to Yann Ylavic from comment #10) > ... unless the client as requests a ... ... unless the client *also* requests a ... -- 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 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #10 from Yann Ylavic --- (In reply to Michael Osipov from comment #9) > In my case, to some extend. I have tried with 100 ms and 500 ms. The backend > is on the same machine. Sometimes it works, sometimes curl receives 503. That's a way too short timeout IMHO, you should use the same value as ProxyTimeout (or timeout= parameter if defined). A short timeout is only useful if you want to fail over another balancer member, but in case where there is a single worker it's no different than the usual proxy<=>backend timeout. > But > adding a fixed overhead to each an every request isn't a real solution > because the backend (Tomcat) does the right thing. mod_proxy_http should > probably react on the immediate close. Which overhead? There is no round-trip here unless the client as requests a 100-continue, and in case of final response issued directly by the backend there is no overhead at 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 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #9 from Michael Osipov --- (In reply to Yann Ylavic from comment #8) > Can't the ProxyPass ping= parameter help here, such that mod_proxy_http > issues a 100-continue negotiation with the backend (even if the client did > not ask for it)? > > In latest mod_proxy versions, if the response to the 100-continue > negotiation is not a "100 continue" status from the backend, then the > response is forwarded directly to the client (the request body is never sent > to the backend). In my case, to some extend. I have tried with 100 ms and 500 ms. The backend is on the same machine. Sometimes it works, sometimes curl receives 503. But adding a fixed overhead to each an every request isn't a real solution because the backend (Tomcat) does the right thing. mod_proxy_http should probably react on the immediate close. -- 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 60717] mod_proxy_http fails with 502 when backend sends 401 and closes connection immediately
https://bz.apache.org/bugzilla/show_bug.cgi?id=60717 Yann Ylavic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Yann Ylavic --- This is fixed in 2.4.43 with end to end 100-continue negotiation. If the backend (Jetty) responds with a final status to a 100-continue request then mod_proxy will forward the response without ever trying to forward the request body. -- 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 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #8 from Yann Ylavic --- Can't the ProxyPass ping= parameter help here, such that mod_proxy_http issues a 100-continue negotiation with the backend (even if the client did not ask for it)? In latest mod_proxy versions, if the response to the 100-continue negotiation is not a "100 continue" status from the backend, then the response is forwarded directly to the client (the request body is never sent to the backend). -- 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 64016] Apache HTTPD intermittently report errors AH01084 and AH01097 with 502
https://bz.apache.org/bugzilla/show_bug.cgi?id=64016 Ankur Joshi changed: What|Removed |Added URL||https://www.newgrouplink.co ||m/ -- 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 63366] POST body is empty when REQUEST is send with transfer-encoding:chunked
https://bz.apache.org/bugzilla/show_bug.cgi?id=63366 --- Comment #3 from Ankur Joshi --- Visit This page may help you thankyou!!!... https://funnygroupnames.xyz/ https://www.newgrouplink.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 39913] detection of static OpenSSL libraries requiring libz fails
https://bz.apache.org/bugzilla/show_bug.cgi?id=39913 --- Comment #8 from Ankur Joshi --- https://funnygroupnames.xyz/ -- 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 60142] 6107 Segmentation fault $HTTPD -k $ARGV in centos 7
https://bz.apache.org/bugzilla/show_bug.cgi?id=60142 --- Comment #1 from Ankur Joshi --- https://www.newgrouplink.com/ Check this out!!! May help!! -- 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 60717] mod_proxy_http fails with 502 when backend sends 401 and closes connection immediately
https://bz.apache.org/bugzilla/show_bug.cgi?id=60717 --- Comment #3 from Michael Osipov --- Here is another in-detail description of the issue: https://www.mail-archive.com/users@tomcat.apache.org/msg135207.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 64016] Apache HTTPD intermittently report errors AH01084 and AH01097 with 502
https://bz.apache.org/bugzilla/show_bug.cgi?id=64016 --- Comment #2 from Michael Osipov --- Here is another in-detail description of the issue: https://www.mail-archive.com/users@tomcat.apache.org/msg135207.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 61090] mod_proxy gives 502 on early HTTP response (3xx, 4xx, 5xx)
https://bz.apache.org/bugzilla/show_bug.cgi?id=61090 --- Comment #7 from Michael Osipov --- Here is another in-detail description of the issue: https://www.mail-archive.com/users@tomcat.apache.org/msg135207.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 64462] New: [Feature Request] Support for HTTP/3
https://bz.apache.org/bugzilla/show_bug.cgi?id=64462 Bug ID: 64462 Summary: [Feature Request] Support for HTTP/3 Product: Apache httpd-2 Version: 2.4.43 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: All Assignee: bugs@httpd.apache.org Reporter: julianpaniaguafi...@gmail.com Target Milestone: --- When will Apache2 support the new HTTP/3 version of the protocol? Major browsers (Chrome, Firefox, etc.) now have support for HTTP/3 (stable versions), so it's not a bad idea to start working on a HTTP/3 module. -- 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 64452] modproxy.tmp Files filling up /tmp after upgrade to 2.4.43
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452 --- Comment #14 from Bernhard Friedreich --- (In reply to Yann Ylavic from comment #13) > Is there something special on your system that prevent opened file to be > removed? It shouldn't be an issue on unix systems usually. Between updating from 2.4.41 and 2.4.43 nothing changed on those servers so I guess it has nothing to do wit anything special on our servers.. (In reply to Yann Ylavic from comment #12) > You could attach to a worker pid, but I wouldn't recommend that on a > production server anyway, it's going to catch all the requests passing > through which will be hard to debug and disturb your production. > I can already reproduce the problem on one of our test environments so I should be able to do this.. worst case I can even also get root there. (In reply to Yann Ylavic from comment #12) > Can you run "strace" on a worker pid? Something like "strace -p > 2>/tmp/strace.out", but it may require sudo too.. > If it works, let it run a little while to see if > unlink("/tmp/modproxy.tmp.xxx") gets called (and succeeds). I'll try this later but I guess it has nothing to do with unlink not working and more to do that those files simply weren't created <= 2.4.41.. -- 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 64452] modproxy.tmp Files filling up /tmp after upgrade to 2.4.43
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452 --- Comment #13 from Yann Ylavic --- (In reply to Ruediger Pluem from comment #11) > Why should a failing cleanup kill the cleanup chain? If the cleanups are run > by apr_pool_clear or apr_pool_destroy no return code is checked and the > cleanup functions in the chain are all executed regardless of their return > value. Yeah, I don't know why I thought that.. I can't see any reason for that file stay then, it should be cleaned up with the request (i.e. always), and there seems to be no child crash. (In reply to Bernhard Friedreich from comment #0) > > Using systemd with PrivateTmp enabled the files are cleaned up on restart of > the unit. If using "legacy" sysv init Scripts we need to stop httpd, clean > up /tmp and start up again as httpd still holds a file handle open to every > modproxy.tmp.* file. Is there something special on your system that prevent opened file to be removed? It shouldn't be an issue on unix systems usually. -- 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 64452] modproxy.tmp Files filling up /tmp after upgrade to 2.4.43
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452 --- Comment #12 from Yann Ylavic --- (In reply to Bernhard Friedreich from comment #10) > Is it also possible to attach to a running httpd? I don't have root > permission on the server so I can only start apache using sudo with our > systemd unit. Is it sufficient to connect to the parent pid or do I need to > connect to the right worker pid? You could attach to a worker pid, but I wouldn't recommend that on a production server anyway, it's going to catch all the requests passing through which will be hard to debug and disturb your production. Can you run "strace" on a worker pid? Something like "strace -p 2>/tmp/strace.out", but it may require sudo too.. If it works, let it run a little while to see if unlink("/tmp/modproxy.tmp.xxx") gets called (and succeeds). -- 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 64452] modproxy.tmp Files filling up /tmp after upgrade to 2.4.43
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452 --- Comment #11 from Ruediger Pluem --- (In reply to Yann Ylavic from comment #5) > I can only see a reason for the file to not be cleaned up: another request > cleanup that runs before and fails (killing the cleanup chain). Why should a failing cleanup kill the cleanup chain? If the cleanups are run by apr_pool_clear or apr_pool_destroy no return code is checked and the cleanup functions in the chain are all executed regardless of their return value. -- 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