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

On Mon, 16 Dec 2013 22:29:39 -0600 "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 behavio

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

On Mon, 16 Dec 2013 22:18:46 +0100 Rainer Jung wrote: > On 16.12.2013 20:25, William A. Rowe Jr. wrote: > > On Sat, 14 Dec 2013 10:25:00 +0100 > > Kaspar Brand wrote: > > > >> Just unload mod_proxy_http and mod_ssl > >> from the configuration, and you'll find that forward proxying > >> https://

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

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 simply > > rely on RFC2817 to document that you are wrong,

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

On Sat, Dec 14, 2013 at 9:02 AM, Kaspar Brand wrote: > On 13.12.2013 15:52, Yann Ylavic wrote: > > I can't tell whether this applies to all the other SSL parameters though > > (most -if not all?- seem to be handled the same way in ssl_hook_Access(), > > but I didn't do an exhaustive search to tell

[PATCH] proxy_util.c: ap_proxy_determine_connection connecting improper HTTPS backend

If an (improper) backend server could only serve requests with "abs_path"s but not "absoluteURI"s (RFC 2616 5.1.2) we couldn't place this backend behind a forward proxy using https. https://issues.apache.org/bugzilla/show_bug.cgi?id=55892 This patch would solve this. I've added the "force-proxy-r

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

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 != 200) { return ftp_proxyerror(r, backend, HTTP_

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

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.

Re: mod_proxy, oooled backend connections and the keep-alive race condition

Hi Yann, Am 09.12.2013 00:30, schrieb Yann Ylavic: > Now, if trying to send the first bytes of the request immediately fails > because the socket isn't connected anymore (e.g. EPIPE), you *know* that > exactly *none* bits of your current request reached the server. For this > reaso

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

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. This entire thread has been on forward proxy, so I'm glad you

Re: mod_remoteip

Hello Eugene, Thanks for pointing out your bug report 54651. It answers a mystery I had with regard to bug report 55635. - https://issues.apache.org/bugzilla/show_bug.cgi?id=55635 As you can see in comment 1, I submitted results that were somewhat different from those of the bug reporter. In co

Event and atomics, round II

Now that 2.4.7 has been out for awhile, I would have assumed that if people were hitting the "atomics not working as expected" error (using unsigned as signed), we would have started hearing about it... But, afaik, we haven't. So this leads me to the following discussion: should we stay with the "