Hi ! it is me again with same old issue - HTTP get via proxy. I am trying to debug Curl (7.37.0, iOS 7.0).
Just for convenience: my case is : Client does HTTP GET to https://www.google.com via Proxy which requires NTLM authentication. I run two cases for comparative analysis of state transitions. First is HTTP GET without proxy and second is with Proxy. In the first case, Curl sends TLS Client Hello in the WAITCONNECT state and then switches to PROTOCONNECT state In the second case, however, Curl sends TLS Client Hello in WAITPROXYCONNECT state and then it switches to WAITCONNECT state (and gets stuck there) - is this correct? should it go to PROTOCONNECT? or, alternatively avoid initiating TLS handshake and go to WAITCONNECT state and let this state to send Client Hello? As I understand now, PROTOCONNECT means "protocol specific connect", so I expect SSL handshake to complete in this state. In my test runs, in the first case (which runs successfully), the following state transitions take place: (I omitted many details, just concentrating on state transitions and external events) 1. INIT --> CONNECT 2. in CONNECT state, Curl initiates socket opening the server and goes to WAITCONNECT state. depending on DNS cache state, this may go to WAITRESOLVE state and then to WAITCONNECT. 3. in WAITCONNECT state: - (when received connected event) sends TLS handshake, Client hello(1) message to the server - goes to PROTOCONNECT state 4. in the PROTOCONNECT state: - TLS handshake takes place (server hello, certificates, key exchanges, etc.) - SSL socket to the server has been established - goes to WAITDO state 5. in the WAITDO state - goes to DO state 6. in the DO state - sends HTTP GET to the server - goes to DO_DONE state 7. in the DO_DONE state - goes to WAITPERFORM state 8. in the WAITPERFORM state - goes to PERFORM state 9. in the PERFORM state - received 302 Found message from the server (it could as well get 200 OK and finish here), it redirects from www.google.com to www.google.co.uk. - starts second iteration, by going to CONNECT state, to follow the redirect. - and in the second iteration (thru the same states) it gets 200 OK (via different connection) I could avoid this iteration if I do GET to www.google.co.uk. in the second case, the following state transitions take place: 1. INIT --> CONNECT 2. in CONNECT state, Curl initiates socket opening the proxy and goes to WAITCONNECT state. 3. in WAITCONNECT state: - sends HTTP CONNECT with NTLM Type 1 message to Proxy - goes to WAITPROXYCONNECT state 4. in the WAITPROXYCONNECT state: - receives 407 error and NTLM Type 2 message (+ KeepAlive set on, as expected) from the Proxy - sends HTTP CONNECT with NTLM Type 3 message to the Proxy - receives 200 OK (and direct socket to google's webserver is established) - sends TLS handshake, Client hello(1) message to the server - goes to WAITCONNECT state 5. in the WAITCONNECT state - gets stuck....... forever I think that Curl should either check for proxy in the WAITCONNECT and the fact that SSL handshake has been initiated and then go to PROTOCONNECT. Or, better, WAITPROXYCONNECT should switch to PROTOCONNECT, not to WAITCONNECT state. ALibek On Tue, Oct 21, 2014 at 11:36 PM, Daniel Stenberg <[email protected]> wrote: > On Wed, 15 Oct 2014, Alibek Joraev wrote: > > I tried my test with Curl 7.37.0 and it works fine. so this problem >> occurs >> only in 7.38.0 >> > > Exactly, that's because commit a4cece3d47cf was made for 7.38.0. We've > already concluded that. > > The question is why it fails, or how it should be fixed. I can't repeat > your problem and you haven't described it with details enough for me to > figure it out in my end. > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
