On Tue, Dec 17, 2013 at 5:44 AM, William A. Rowe Jr.
wrote:
>
> On Mon, 16 Dec 2013 22:29:39 -0600
> "William A. Rowe Jr." wrote:
>
> > My defect is really very simple, Here's a request to proxy.example.com
> > created in order to tunnel an https connection to server.example.com;
> >
> >CONNE
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 compre
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
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand 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 finally agreed.
On 17.12.2013 05:29, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand 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 whether I can sim
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
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
William A. Rowe Jr. wrote:
> On Fri, 13 Dec 2013 10:46:43 +0100
> Ruediger Pluem 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
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: ssl_eng
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 != 2
10 matches
Mail list logo
