Re: [Openvpn-devel] HTTP/1.1 Host header
> 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 implying is that if a request is sent, the part after 'CONNECT' must be always the same as the part after 'Host'. > I'll ack your patch if it only adds a Host header where one is > missing, and sends the correct contents, ie. the "remote" hostname. Hopefully the attached patch is acceptable for you. Lars --- openvpn-2.1.3.orig/proxy.c 2010-09-26 23:05:46.0 +0100 +++ openvpn-2.1.3/proxy.c 2010-09-29 15:50:55.0 +0100 @@ -551,6 +551,10 @@ /* send HTTP CONNECT message to proxy */ if (!send_line_crlf (sd, buf)) goto error; + + openvpn_snprintf(buf, sizeof(buf), "Host: %s", host); + if (!send_line_crlf(sd, buf)) +goto error; /* send User-Agent string if provided */ if (p->options.user_agent) smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] HTTP/1.1 Host header
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 clients. On the other hand, if OpenVPN only ever CONNECTs, maybe it's not an issue. Lars Hupel wrote: > As far as I can see, there are two possible hosts which can be sent: > > * 'host' (denoting the 'remote' config option) > * 'p->options.server' (denoting the 'http-proxy' config option) > > I would guess that sending the latter would be correct, but the > OpenVPN sources use the first one. Current behavior is correct. The first one is what should be sent. > The section about the host header isn't very helpful either: > > >The Host request-header field specifies the Internet host and port > >number of the resource being requested, as obtained from the original > >URI given by the user or referring resource (generally an HTTP URL 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. I'll ack your patch if it only adds a Host header where one is missing, and sends the correct contents, ie. the "remote" hostname. //Peter
Re: [Openvpn-devel] HTTP/1.1 Host header
> 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 Required". Maybe it is possible to move > this into an extra function, maybe send_proxy_headers. Apparently I was mistaken at this point. With the very first place where an HTTP CONNECT is issued being the only exception, at all other places the Host header is sent. However, I'm not sure whether these are correct. As far as I can see, there are two possible hosts which can be sent: * 'host' (denoting the 'remote' config option) * 'p->options.server' (denoting the 'http-proxy' config option) I would guess that sending the latter would be correct, but the OpenVPN sources use the first one. For example, consider the following configuration: http-proxy-option VERSION 1.1 http-proxy vpn.example.com 80 remote localhost 1194 I would expect the OpenVPN client to send the request as following (over a connection with vpn.example.com:80): CONNECT localhost:1194 HTTP/1.1 Host: vpn.example.com At the moment (and with the patch proposed in 2008), the following request is sent: CONNECT localhost:1194 HTTP/1.1 Host: localhost The problem is that the RFC isn't clear at that point. Consider the following snippet from the section about 'CONNECT': >This specification reserves the method name CONNECT for use with a >proxy that can dynamically switch to being a tunnel (e.g. SSL >tunneling [44]). The section about the host header isn't very helpful either: >The Host request-header field specifies the Internet host and port >number of the resource being requested, as obtained from the original >URI given by the user or referring resource (generally an HTTP URL >[...] From this, I would remotely guess that my proposal is correct. I didn't receive an answer from the Apache folks yet about how mod_proxy_connect differentiates between multiple VirtualHosts. My short experiments only showed indifferent behavior, so maybe some of you who have more experience could tell. For completeness' sake I've attached the appropriate patch (without HTTP version check, as described earlier). Please let me know what you think about it. Lars --- openvpn-2.1.3.orig/proxy.c 2010-09-26 23:05:46.0 +0100 +++ openvpn-2.1.3/proxy.c 2010-09-29 15:50:55.0 +0100 @@ -551,6 +551,10 @@ /* send HTTP CONNECT message to proxy */ if (!send_line_crlf (sd, buf)) goto error; + + openvpn_snprintf(buf, sizeof(buf), "Host: %s", p->options.server); + if (!send_line_crlf(sd, buf)) +goto error; /* send User-Agent string if provided */ if (p->options.user_agent) @@ -676,7 +680,7 @@ /* send HOST etc, */ - openvpn_snprintf (buf, sizeof(buf), "Host: %s", host); + openvpn_snprintf (buf, sizeof(buf), "Host: %s", p->options.server); msg (D_PROXY, "Send to HTTP proxy: '%s'", buf); if (!send_line_crlf (sd, buf)) goto error; @@ -787,7 +791,7 @@ goto error; /* send HOST etc, */ - openvpn_snprintf (buf, sizeof(buf), "Host: %s", host); + openvpn_snprintf (buf, sizeof(buf), "Host: %s", p->options.server); msg (D_PROXY, "Send to HTTP proxy: '%s'", buf); if (!send_line_crlf (sd, buf)) goto error; smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] HTTP/1.1 Host header
> 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 field." > > The client also "MUST" send a Host: header in every request, it is not > an optional field. Changing only the version number on the CONNECT line > OpenVPN sends does not make it a real HTTP/1.1 request. I would second that and therefore consider this behaviour as a bug. Additionally, my setup requires to have all VirtualHosts on Port 80, so without the header an effective disambiguation is impossible. Lars smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] HTTP/1.1 Host header
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 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 field." The client also "MUST" send a Host: header in every request, it is not an optional field. Changing only the version number on the CONNECT line OpenVPN sends does not make it a real HTTP/1.1 request. (From what I can tell, and based on a very quick test, the string "_default_" in an Apache config also only matches unlisted IP addresses, and does not change how it processes HTTP requests that claim to be version 1.1 but aren't.) -- Heikki Kallasjoki heikki.kallasj...@iki.fi
Re: [Openvpn-devel] HTTP/1.1 Host header
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 Host header is missing, so I get "Bad Request" responses. Additionally, without Host header it's impossible to use Apache's VirtualHost facility. Regards Lars 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 DocumentRoot /www/default1234 ... DocumentRoot /www/default80 ... etc but this seems like an easy patch. Perhaps someone else on the -devel list can comment on why it was not accepted... cheers, JJK
Re: [Openvpn-devel] HTTP/1.1 Host header
> 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 missing, so I get "Bad Request" responses. Additionally, without Host header it's impossible to use Apache's VirtualHost facility. Regards Lars smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] HTTP/1.1 Host header
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 (subject was "enhance compatibility with HTTP/1.1 proxies", from Frank Behrens) about a very similar patch. However, I was not able to extract from that discussion why the patch was rejected (or simply ignored?). Are there any objections to accept the patch? 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? HTH, JJK
[Openvpn-devel] HTTP/1.1 Host header
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 "enhance compatibility with HTTP/1.1 proxies", from Frank Behrens) about a very similar patch. However, I was not able to extract from that discussion why the patch was rejected (or simply ignored?). Are there any objections to accept the patch? Regards, Lars smime.p7s Description: S/MIME Cryptographic Signature
