Serf Shouldn't add entire URI to Request line for all proxy requests

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set up a nice squid proxy (or charles)
2. set up your serf context to use a proxy
3. try to connect to an ssl server through said proxy
4. you will notice in the request line includes the hosts URI this breaks TLS 
on the other side...

What is the expected output? What do you see instead?
a normal request line

What version of the product are you using? On what operating system?
1.0.0

Please provide any additional information below.

Original issue reported on code.google.com by gradypla...@gmail.com on 15 Mar 2012 at 9:59

[GoogleCodeExporter]

Hi. Can you clarify a bit?

In the described setup, serf will first try to set up a ssl tunnel. So it 
starts with:
CONNECT svn.apache.org:443 HTTP/1.1

Once the proxy has successfully set up the tunnel, all further requests will 
use an absoluteUri:
PROPFIND https://svn.apache.org/repos/asf/!svn/rvr/1384224 HTTP/1.1

Are you referring to the first or second request line?

As the first is standard RFC 2817 stuff, I suppose you are referring to the 
second. In that case I'm interested to know what you see as error. Do you get 
an error back from the server? Is there anything in the server logs?

Lieven

Original comment by lieven.govaerts@gmail.com on 13 Sep 2012 at 7:59

[GoogleCodeExporter]

Isn't the second request supposed to look like this?

PROPFIND /repos/asf/!svn/rvr/1384224 HTTP/1.1
Host: svn.apache.org

Original comment by andreas.stieger@gmx.de on 23 Feb 2013 at 12:00

[GoogleCodeExporter]

I think this is specific to HTTPS requests, where the proxy is only used for an 
outer connection and the inner connection is to the normal webserver.

For HTTP proxying the full hostname requests to the proxy are required, but for 
HTTPS the further requests are 100% to the backing server, so leaving the host 
out might be cleaner.

If I remember correctly HTTP/1.1 allows the full hostname in the first line, 
but not writing it probably improves interop.

Original comment by b...@qqmail.nl on 18 May 2013 at 10:27

[GoogleCodeExporter]

Well, I assume the same thing, but using absoluteURI instead of relativeURI 
should not result in errors.

From RFC 2616 section 5.1.2:
"To allow for transition to absoluteURIs in all requests in future versions of 
HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even 
though HTTP/1.1 clients will only generate them in requests to proxies."

In fact, what I find strange in the description of this issue is that TLS and 
HTTP are not even on the same layer, so it's impossible that TLS breaks due to 
serf's implementation of the HTTP protocol.

So my summary of this issue:
- it would be nice to use the requestURI instead of absoluteURI in requests to 
an HTTPS server using a proxy - patches are welcome to fix this.
- however, current behaviour should not result in errors. All examples were it 
does result in errors are welcome here and I will review them.

Original comment by lieven.govaerts@gmail.com on 18 May 2013 at 11:22

[GoogleCodeExporter]

The CONNECT request creates a transparent proxy, so breaks the layering rules.

As such it is not really HTTP, but more of a proxy request asking for a tunnel.

Original comment by b...@qqmail.nl on 18 May 2013 at 12:39

[GoogleCodeExporter]

Hi,

I was able to receive this server with subversion clients 1.7 and 1.8. I've two 
repositories A, and B on different hosts, both of which are over SSL, and 
require authentication to access.

I use polipo locally on my computer, so I configured ~/.subversion/servers to 
talk to polipo.

Using polipo, I was able to successfully access repository A, but with 
repository B I get 501. I truss-ed the polipo, and it seems like:

1. With repository A, svn client sends "CONNECT repository-a.domain.tld:443 
HTTP/1.1..." and works with that.

2. With repository B, svn client sends "CONNECT repository-b.domain.tld:443 
HTTP/1.1..." and then sends my credentials in a different request with "OPTIONS 
https://repository-b.domain.tld/ HTTP/1.1\r\nWWW-Authenticate:....\r\n"

On investigation between both hosts, I found that repository A's host is having 
Keep-Alive on, whereas repository B has that off. I turned it ON on repository 
B's host, and after that I was able to access it successfully.

I think the description of the issue reported here matches what I observed.

HTH

Original comment by wahj...@gmail.com on 23 Jun 2013 at 10:50

[GoogleCodeExporter]

s/receive this server/reproduce this issue/ sorry a bit sleepy atm

Original comment by wahj...@gmail.com on 23 Jun 2013 at 10:51

[GoogleCodeExporter]

Hi,

what you're seeing is not this particular issue. It's also not a serf issue, 
but a situation that should be handled by ra_serf in Subversion.

Svn+ra_serf+serf will always use persistent connections. In http1.1 mode it's 
just assumed that connections are persistent, in http1.0 mode ra_serf adds the 
Connection:keep-alive headers to all requests.

The first request svn sends over the ssl tunnel to the server is the OPTIONS 
request. 
(The CONNECT request is sent to the proxy but not forwarded to the server)
After that it will continue sending other requests on the same connection. 
Since your host B is configured with KeepAlive off, it will respond to the 
second request with a "501 Not Implemented" response.

Svn considers this '501 Not Implemented" response as an error and stop.

I propose you report this issue on the Subversion developers mailing list. We 
have been discussing similar issues this weekend.

Lieven

Original comment by lieven.govaerts@gmail.com on 24 Jun 2013 at 9:18

[GoogleCodeExporter]

The original issue reported here is fixed in r1952, serf will now use relative 
uri's for the requests sent through an SSL tunnel.

Original comment by lieven.govaerts@gmail.com on 24 Jun 2013 at 9:18

• Changed state: Fixed