DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #18 from Graham Mainwaring 2010-07-16 15:56:29 EDT --- Also, regarding vulnerability CVE-2005-2088, surely this can be solved by improving the header parsing rather than by destroying useful functionality that people were using. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #17 from Graham Mainwaring 2010-07-16 15:46:57 EDT --- I don't think it's HTTP 1.1 abuse. I can't find anything in RFC2068 that speaks to this point one way or the other. I don't think it's required for mod_proxy to implement this, but it certainly would not be RFC-violating to do so. Suppose a back-end server sends a response with content-length: 1000 but only sends 100 bytes. In that case mod_proxy transmits the 100 bytes to the requestor and waits for further data. But if the incoming request has content-length: 1000 but only sends 100 bytes, mod_proxy just sits there. Why not open the request to the back-end right away? It would improve performance even on regular GET requests, because you're making use of time that would otherwise be wasted on network latency to get the back-end connection open, which means you'll be able to generate a response that much faster. If you have all the HTTP headers and part of the request data, what's the benefit in *not* starting the connection to the back-end, since you know you're going to need it? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 William A. Rowe Jr. changed: What|Removed |Added Priority|P4 |P5 Severity|normal |enhancement --- Comment #15 from William A. Rowe Jr. 2010-07-16 14:36:16 EDT --- Ok, so that's a 1GB 'open ended' pipe, and it expected synchronicity which it's absolutely not allowed to do. Thanks for clarifying, that's what I thought you were getting at. Will ponder interesting solutions, but in the interim it is HTTP/1.1 abuse. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 William A. Rowe Jr. changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #16 from William A. Rowe Jr. 2010-07-16 14:36:53 EDT --- Still/now 'new' -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #13 from Hans Maurer 2010-07-16 14:23:03 EDT --- William, actually, there were(*) two parallel HTTP requests, one for traffic from Outlook to Exchange and one for traffic from Exchange to Outlook. The "upstream" request had a Content-Length header of about 2 GB. The initial ticket description (and my other comments from 2006) contain the headers of both requests as well as an analysis why Apache's buffering causes a deadlock on Microsoft's - well - creative RPC over HTTP implementation. (*) That was Outlook 2003 with Exchange 2003. I never checked for Outlook 2007/2010 and Exchange 2008. Best regards, Hans -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #14 from Hans Maurer 2010-07-16 14:24:48 EDT --- (In reply to comment #13) > The "upstream" request had a Content-Length header of about 2 GB. Oh, actually 1 GB, not 2 GB. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 William A. Rowe Jr. changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #12 from William A. Rowe Jr. 2010-07-16 14:14:50 EDT --- If you can remember that the 100-byte request carried 100 byte content-length, or was definitely larger, that would help. Anyone; if you have the opportunity to sniff the httpd -> backend connection and post what leads to this hang on the near side of the conversation, that would be great. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #11 from Hans Maurer 2010-07-16 13:35:26 EDT --- William, since you're addressing me personally: We've move to a VPN-based solution long ago, so I don't need this functionality anymore. However, there several comments votes by other people, and I also occasionally get mails from people asking me how I worked around this problem. So, there still seems to be some demand for this feature out there. Best regards, Hans -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029 --- Comment #10 from William A. Rowe Jr. 2010-07-16 11:37:59 EDT --- Hans, this is an HTTP protocol question, unrecognized methods are allowed but they must follow HTTP/1.1 itself, and if MS's protocol isn't HTTP/1.1 compliant, we won't be accommodating. HTTP/1.1 is not bi-sync, it is message/resource oriented. You have stated that 100 bytes of the request message are sent, and that we are blocking for 8kb; what is the Content-Length header of this case? There is a not-altogether unreasonable solve to this but it's not trivial; use proxy_connect for specific methods which turn out to be HTTP/1.1 non-compliant, which would turn the tunnel into a connection stream. Patches welcome. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49604] New: bad debug message for MCacheMaxStreamingBuffer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49604 Summary: bad debug message for MCacheMaxStreamingBuffer Product: Apache httpd-2 Version: 2.2.15 Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: mod_cache AssignedTo: bugs@httpd.apache.org ReportedBy: cove...@gmail.com Created an attachment (id=25770) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25770) patch with new debug msg If mod_mem_cache is caching a streaming (chunked) response, and the size eventually exceeds MCacheMaxStreamingBuffer, the only thing logged is a debug message: [Fri Jul 16 10:27:00 2010] [debug] mod_cache.c(391): (12)Cannot allocate memory: cache: Cache provider's store_body failed! In the non-streaming case, where the size is known up-front and compared to min/max object size, the message is more explicit. I'd like to add another debug message like: [Fri Jul 16 10:27:00 2010] [debug] mod_mem_cache.c(825): mem_cache: URL http://localhost:80/bigfile? failed the MCacheMaxStreamingBuffer (10) check and will not be cached. (mem_cache is not in trunk and did not want to jump straight to STATUS) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49602] Peruser made as a core feature in httpd.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49602 Jeff Trawick changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Jeff Trawick 2010-07-16 09:57:41 EDT --- The developers of peruser would need to approach the project themselves, via the d...@httpd mailing list or perhaps via priv...@httpd.apache.org if they want to explore the possibility quietly. Future httpd 2.4 will support loadable MPMs (i.e., switch MPMs by changing the LoadModule directive), so it becomes much easier to consume MPMs provided by third parties. As a peruser user, you could engage the peruser developers w.r.t. httpd 2.4 support (and resolving any nuances with loadability) and help ensure that peruser is ready for 2.4 at GA. (See http://httpd.apache.org/ for a notice of the current alpha.) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49602] New: Peruser made as a core feature in httpd.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49602 Summary: Peruser made as a core feature in httpd. Product: Apache httpd-2 Version: 2.2.15 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Core AssignedTo: bugs@httpd.apache.org ReportedBy: fl...@itnews-bg.com Hey, I know this is not the place for my suggestion but I couldn't find any other contact form or way to submit it. I'm sorry for posting it here. For some time now I have been monitoring Peruser MPM ( http://www.peruser.org/trac/peruser/ ). The feature is really useful for web hosting companies and also for homemade servers used by developers. Is it possible this feature becomes a part of apache ? The person who writes the patches has already done patches for the sources of apache 2.2.3-2.2.14. My point is that he has already done the code - you'll just have to import it in your newer releases? P.S. I don't know the owner and if he'd accept this suggestion but I think apache really needs something like this as an core feature. Wish you all the best, Me -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
