Fix reusing ASIO http_client connecting to HTTPS server via proxy#539
Fix reusing ASIO http_client connecting to HTTPS server via proxy#539BillyONeal merged 2 commits intomicrosoft:masterfrom
Conversation
Calling request() twice on the same client configured to connect to a server via HTTPS didn't work under Unix because we issues CONNECT for every request, meaning that, for the second one, we sent CONNECT via an already established connection to the end server itself which, unsurprisingly, didn't work at all. Fix this by only setting up SSL tunnelling for a new connection but not for the already used one.
|
It might also be worth updating the |
|
@BillyONeal This issue is a dealbreaker for us right now. We currently patch the source locally since this fix works as expected on any ASIO implementation. If @vadz does not supply a test-case we are probably better off creating a new PR that contains this fix and the required reuse-connection test. Or, just skip the test, merge this, and add a test later on 🙈? This PR will by far fix the reuse connection issue through proxies over HTTPS anyway... We have been using it in production for over a year without issues. |
|
@leetal The problem is that we don't understand what's going on here, so without a test this is likely to be regressed. |
|
@BillyONeal Do you have any specific questions? I don't remember all the details one year on neither, but AFAIR, this was relatively straightforward: you just can't The example to the sample should allow you to reproduce the problem and I can try making this into an automated test if this is really indispensable for the PR to be merged, although I admit I have no idea when will I have time for this... |
…euse # Conflicts: # Release/src/http/client/http_client_asio.cpp
|
Looking at this again I think it makes sense enough to merge. I still would prefer to see tests though :) |
|
Thanks for merging and sorry for never finding time for this test... |
Calling request() twice on the same client configured to connect to a
server via HTTPS didn't work under Unix because we issues CONNECT for
every request, meaning that, for the second one, we sent CONNECT via an
already established connection to the end server itself which,
unsurprisingly, didn't work at all.
Fix this by only setting up SSL tunnelling for a new connection but not
for the already used one.
The problem can be easily reproduced with the following patch to the BingRequest sample:
Running the sample without this PR would result in something like
where 403 is the status returned by the actual server (and not the proxy) when it receives
CONNECT.