Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be "Connection Established".
Is it always "HTTP/1.1" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kenjis You are right, I'm studying now whole concept behind this and it seems that there should be different headers.
The original tunnelling spec required the proxy to return a
200 Connection Establishedto the client once it had successfully connected to the server, which is what we're seeing. This is potentially followed by more headers, and then an empty line, before the connection becomes transparent and we get the actual response from the server. So, we get two sets of headers. RFC 2817 relaxes this, and allows any 2xx response to a CONNECT request.Some very late clarification. When you connect to an SSL/TLS server through a proxy, the proxy establishes a tunnel, using HTTP CONNECT. This is covered in RFC2817 and the expired tunneling spec, and not RFC261.
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:
some proxies are rather minimalist and only give:
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.