Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Yann Ylavic
On Tue, Dec 17, 2013 at 5:44 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Mon, 16 Dec 2013 22:29:39 -0600 William A. Rowe Jr. wr...@rowe-clan.net wrote: My defect is really very simple, Here's a request to proxy.example.com created in order to tunnel an https connection to

Revisiting: xml2enc, mod_proxy_html and content compression

2013-12-17 Thread Thomas Eckert
I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do the detection magic but mod_xml2enc fails to detect compressed content correctly. Hence a simple ProxyHTMLEnable fails when content compression is in place. To work around this without dropping support for content

Re: Revisiting: xml2enc, mod_proxy_html and content compression

2013-12-17 Thread Nick Kew
On 17 Dec 2013, at 10:32, Thomas Eckert wrote: I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do the detection magic but mod_xml2enc fails to detect compressed content correctly. Hence a simple ProxyHTMLEnable fails when content compression is in place. Aha!

Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Kaspar Brand
On 16.12.2013 20:25, William A. Rowe Jr. wrote: On Sat, 14 Dec 2013 10:25:00 +0100 Kaspar Brand httpd-dev.2...@velox.ch wrote: On 14.12.2013 09:36, William A. Rowe Jr. wrote: ProxyPass is not involved in the SSL forward proxy case at all, as I already tried to point out. Good, we've

Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Kaspar Brand
On 17.12.2013 05:29, William A. Rowe Jr. wrote: On Sat, 14 Dec 2013 10:25:00 +0100 Kaspar Brand httpd-dev.2...@velox.ch wrote: On 14.12.2013 09:36, William A. Rowe Jr. wrote: I beg to differ. We are left with a question of whether you are responsible to defend the current behavior, or

Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Kaspar Brand
On 26.11.2013 06:31, Kaspar Brand wrote: As far as PR 55782 is concerned, the problem might be that proxy_util.c:ap_proxy_determine_connection() does not take Host: header differences into account when checking if an existing connection can be reused (not sure). With SNI this would have the

Re: Revisiting: xml2enc, mod_proxy_html and content compression

2013-12-17 Thread Ruediger Pluem
Nick Kew wrote: Returning to: SetOutputfilter INFLATE;xml2enc;proxy-html;DEFLATE AFAICS the only thing that's missing is the nonessential step 4 above. Which can be avoided with a setenvif Request_URI \.gz$ no-gzip Regards Rüdiger

Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Ruediger Pluem
William A. Rowe Jr. wrote: On Fri, 13 Dec 2013 10:46:43 +0100 Ruediger Pluem rpl...@apache.org wrote: William A. Rowe Jr. wrote: Yes, and? Why would this differ from the historical handling of the Host: header? The HTTP Host header is not the dns name of this hop, It doesn't, but we

Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

2013-12-17 Thread Ruediger Pluem
Kaspar Brand wrote: If your goal is to make httpd compatible with Chrome's Secure Web Proxy or another other client doing CONNECT over SSL, that's fine, and I'm not opposed to it (a small change to ssl_hook_ReadReq [attached] I guess a more general fix for this would be: Index:

Re: mod_proxy_ftp: Question about the use of an un-initialized buffer

2013-12-17 Thread Christophe JAILLET
Le 16/12/2013 22:58, Christophe JAILLET a écrit : Hi, in mod_proxy_ftp, in function 'proxy_ftp_handler', there is 8ko of stack reserved for the variable: char buffer[MAX_STRING_LEN] However, this buffer is never filled within the function and its only use is at line 1675: if (rc !=