curl-library
proxy's response to CONNECT included with server's response
Date: Wed, 5 Oct 2005 09:19:50 -0400
When making an https request through a proxy, a CONNECT request is of
course made to the proxy before the SSL connection can be made with the
remote server.
Currently, the proxy's response to the CONNECT is written to the libcurl
callback function like the rest of the response, such that it appears
before the remote server's response headers. So, for instance, to my
client code, the response looks like this:
HTTP/1.0 200 Connection established <-- proxy's response
Proxy-agent: tinyproxy/1.6.3
HTTP/1.0 200 OK <-- remote server's response
Date: Tue, 04 Oct 2005 20:17:22 GMT
etc
some proxies are rather minimalist and only give:
HTTP/1.0 200 <-- proxy's response
HTTP/1.0 200 OK <-- remote server's response
Date: Tue, 04 Oct 2005 20:17:22 GMT
etc
The best method I have thought of for detecting whether the response
contains a header like this (with a proxy's CONNECT response first) is
to set a header callback and see if I get an empty header line in the
middle of the headers. I haven't actually tested this solution yet.
Ideally, it would be nice if libcurl could strip the proxy's response to
the CONNECT completely (when successful), so my callback only sees:
HTTP/1.0 200 OK <-- remote server's response
Date: Tue, 04 Oct 2005 20:17:22 GMT
etc
I have an old version of the curl command-line tool (7.10.6) which
appears to have worked this way -- stripping the proxy's CONNECT request
such that the headers dumped with -D are only those from the remote
server. So presumably the behavior was changed intentionally at some
point, or there is an option in libcurl which I am missing. Assuming
there is no option currently, perhaps one could be added to libcurl to
specify whether the client wants to ignore the proxy's CONNECT response
if it was successful?
Are there any other solutions I'm missing? I could try to determine
whether a proxy is in use by checking environment variables, etc., and
checking whether a "https" url was requested, but this seems more error
prone and ugly. I'd like to leave those details to libcurl.
Thanks.
David
Received on 2005-10-05