> Current behavior is correct. The first one is what should be sent.
> [...]
> Actually it is helpful. It says that *the resource being requested as
> obtained from the original URI given by the user* is what should be
> sent. This is the "remote" parameter and nothing else.
So what you're implyin
Lars Hupel wrote:
> I would suggest to always send the Host header (even when HTTP/1.0
> is selected).
I strongly support this. Please watch out for HTTP/1.1, if a client
claims to support 1.1 then servers can respond e.g. with chunked
transfer coding, which certainly isn't supported by 1.0 client
> After looking into the source code, there are (at least) two places
> where this patch has to be applied.
>
> 1) The place described earlier and mentioned in the original patch (I
> would guess)
> 2) There is duplicated code in the same function when the proxy answered
> with "407 Proxy Authenti
After looking into the source code, there are (at least) two places
where this patch has to be applied.
1) The place described earlier and mentioned in the original patch (I
would guess)
2) There is duplicated code in the same function when the proxy answered
with "407 Proxy Authentication Require
Hi ,
Heikki Kallasjoki wrote:
On Mon, Sep 27, 2010 at 02:22:00PM +0200, Jan Just Keijser wrote:
ah right, now I see... hmmm 'Host: ...' headers should not be required
by a web server and with apache's Virtual Hosts you can override this using
I would have to disagree with whether Host
> I would have to disagree with whether Host: headers should be required,
> given that the HTTP/1.1 specification explicitly says [RFC2616]:
>
> "All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad
> Request) status code to any HTTP/1.1 request message which lacks a Host
> header fiel
On Mon, Sep 27, 2010 at 02:22:00PM +0200, Jan Just Keijser wrote:
> ah right, now I see... hmmm 'Host: ...' headers should not be required
> by a web server and with apache's Virtual Hosts you can override this using
I would have to disagree with whether Host: headers should be required,
given th
Lars Hupel wrote:
I'm not sure if I understand the question ; openvpn already has the
option to use http/1.1 headers using
--http-proxy-option VERSION 1.1
which should send HTTP/1.1 type messages - doesn't that work?
The problem is that (at least Apache) rejects these requests because the
> I'm not sure if I understand the question ; openvpn already has the
> option to use http/1.1 headers using
> --http-proxy-option VERSION 1.1
> which should send HTTP/1.1 type messages - doesn't that work?
The problem is that (at least Apache) rejects these requests because the
Host header is mi
Lars Hupel wrote:
Hi,
as the subject states, I would like that OpenVPN sends an appropriate
Host header, because my server configuration relies on Apache's
VirtualHosts. Because OpenVPN doesn't send this header, I patched it
myself. Recently, I found the discussion on openvpn-devel from 10/2008
Hi,
as the subject states, I would like that OpenVPN sends an appropriate
Host header, because my server configuration relies on Apache's
VirtualHosts. Because OpenVPN doesn't send this header, I patched it
myself. Recently, I found the discussion on openvpn-devel from 10/2008
(subject was "enhanc
11 matches
Mail list logo
