[Bug 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 Yann Ylavic changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- 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 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 Yann Ylavic changed: What|Removed |Added Attachment #35722|0 |1 is obsolete|| -- 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 62044] shared memory segments are not found in global list, but appear to exist in kernel.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62044 Yann Ylavic changed: What|Removed |Added Attachment #35702|0 |1 is obsolete|| --- Comment #34 from Yann Ylavic --- Created attachment 35723 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35723&action=edit Reuse SHMs names on restart or stop/start (2.4.x) This is the full patch proposed to be backported to 2.4.next. It should reuse the SHMs names as much as possible on restart or stop/start, which should address the increasing number of IPCs on the system if/when the parent process crashes. Please note that it won't reuse SHMs if by some means children process from an old httpd instance (whose parent process crashed) are still alive, this is not something desirable. Could you test it with your large configuration? -- 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 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 ufifa changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Ever confirmed|1 |0 Resolution|FIXED |--- -- 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 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 ufifa changed: What|Removed |Added CC||dr.m1...@outlook.com --- Comment #27 from ufifa --- Created attachment 35722 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35722&action=edit http://www.ufifa.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 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 Christopher Schultz changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #26 from Christopher Schultz --- (In reply to Ruediger Pluem from comment #25) > > > > (In reply to Jim Jagielski from comment #22) > > > Of course exposing resources unintentionally is EVIL. That is why when > > > there > > > is the possibility, it is logged so allow the admin, who is the final > > > arbitrator, to determine if they are exposed or not. > > > > Unfortunately, the log is only advisory. httpd continues to start up in what > > I would describe generously as a "degraded" condition... one where a > > (likely) larger URL space will be proxied than initially intended. > > I would completely agree if this would be the case, but it isn't. The error > messages tells you that the worker name was truncated. This is unrelated to > the request URL that is forwarded. The truncated worker name only means that > if you have multiple ProxyPass directives and if the truncation of the > worker name leads to the same worker name they use the same connection pool > for the backend connections. This is no issue at all, contrawise: It saves > resources on the backend. Thanks for that clarification. To re-phrase, the worker name is being truncated, but incoming URLs will not be truncated for comparison, yes? Could this become a problem is if the hostname of the origin server is something insanely long? For example, if I want two workers like http://super-long-hostname:80/ and http://super-long-hostname:81/ and those "super-long-hostname" names exceed the worker-name limit, they will be considered the same worker, yes? That means that requests that should go to e.g. port 81 might end up instead going to port 80. -- 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 53218] ProxyPass worker name (http://localhost:3128/...) too long
https://bz.apache.org/bugzilla/show_bug.cgi?id=53218 Ruediger Pluem changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #25 from Ruediger Pluem --- > > (In reply to Jim Jagielski from comment #22) > > Of course exposing resources unintentionally is EVIL. That is why when there > > is the possibility, it is logged so allow the admin, who is the final > > arbitrator, to determine if they are exposed or not. > > Unfortunately, the log is only advisory. httpd continues to start up in what > I would describe generously as a "degraded" condition... one where a > (likely) larger URL space will be proxied than initially intended. I would completely agree if this would be the case, but it isn't. The error messages tells you that the worker name was truncated. This is unrelated to the request URL that is forwarded. The truncated worker name only means that if you have multiple ProxyPass directives and if the truncation of the worker name leads to the same worker name they use the same connection pool for the backend connections. This is no issue at all, contrawise: It saves resources on 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
