Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
HttpClient issue resolving IP
#11
Maybe so, but usually it's not an issue. It will mean that the client is going to connect, get a page, and disconnect, instead of trying to keep a connection open. But most servers are quite happy with that.

Oh, wait, you are sending a POST command and the browser is using a GET. That would definitely cause issues if the server is waiting for a GET. Are you sure you are calling DoSSLGET()? I traced down and it sure looks like it should be passing GET if you are calling the GET method.
Dean Roddey
Explorans limites defectum
Reply
#12
Dean Roddey Wrote:Maybe so, but usually it's not an issue. It will mean that the client is going to connect, get a page, and disconnect, instead of trying to keep a connection open. But most servers are quite happy with that.

Oh, wait, you are sending a POST command and the browser is using a GET. That would definitely cause issues if the server is waiting for a GET. Are you sure you are calling DoSSLGET()? I traced down and it sure looks like it should be passing GET if you are calling the GET method.

Yes, I changed back to a POST when I removed the SSL. That is the way others have gotten it to work. I had tried a SSL GET just to match what the browser was sending. But, neither one (POST or GET) works when sent from the CQC HttpClient.
Reply
#13
Dean Roddey Wrote:Maybe so, but usually it's not an issue. It will mean that the client is going to connect, get a page, and disconnect, instead of trying to keep a connection open. But most servers are quite happy with that.

Oh, wait, you are sending a POST command and the browser is using a GET. That would definitely cause issues if the server is waiting for a GET. Are you sure you are calling DoSSLGET()? I traced down and it sure looks like it should be passing GET if you are calling the GET method.

Here's what happens with a GET to port 80 via the CQC Client:

GET /user/login HTTP/1.0
Host: home.nest.com
User-Agent: Nest/3.0.1.15 (iOS) os=6.0 platform=iPad3,1
Accept: */*


HTTP/1.1 400 BAD_REQUEST
Content-Length: 0
Connection: Close

The browser gets a 301 Redirect instead of a bad request.

My last stab will be to try and send the exact same headers as the browser and see what happens. If that doesn't work, I think we are SOL for a pure CQC driver for this thing.
Reply
#14
Thinking about it a bit more... If what you are doing it trying to emulate an actual person logging in by querying a login page and then sending the login credentials as though they were posted from that page, then yeh, probably it does assume a persistent SSL connection. That would make sense.

Why not try just sending what the browser sends for the actual login instead if that's the case. I.e. don't ask for the page, just act as though you already have it.

For the SSL stuff I'm using the WinHTTP stuff in Windows, and just wrapping those calls down in the platform kernel. I'm not doing anything to indicate a specific HTTP version, so presumably it's defaulting to that and I'd have to do something else to create a 1.1 session and a persistent session, which would also require new APIs because I assume it would have to return some sort of session object that would be used for subsequent calls and eventually have to be closed.
Dean Roddey
Explorans limites defectum
Reply
#15
Wait, the WinHttpOpenRequest() function indicates that if you don't indicate explicitly, it uses 1.1.

It does support persistent connections, but as indicated above that would require a whole different type of set of methods, to initiate, use, and then close such a connection.
Dean Roddey
Explorans limites defectum
Reply
#16
Dean Roddey Wrote:Thinking about it a bit more... If what you are doing it trying to emulate an actual person logging in by querying a login page and then sending the login credentials as though they were posted from that page, then yeh, probably it does assume a persistent SSL connection. That would make sense.

Why not try just sending what the browser sends for the actual login instead if that's the case. I.e. don't ask for the page, just act as though you already have it.

For the SSL stuff I'm using the WinHTTP stuff in Windows, and just wrapping those calls down in the platform kernel. I'm not doing anything to indicate a specific HTTP version, so presumably it's defaulting to that and I'd have to do something else to create a 1.1 session and a persistent session, which would also require new APIs because I assume it would have to return some sort of session object that would be used for subsequent calls and eventually have to be closed.

I'm not trying to emulate a user working through the browser.

There is an undocumented REST API for the thermostat that returns JSON.

I'm just accessing the resource URL for login which it just so happens you can do through a browser too. Makes it nice to test.

One other thing that is different between HTTP 1.0 and 1.1 is the support for more header values (like the ones the browser sends on the GET). I'm going to specify those and see what happens - maybe I'll get lucky somehow.
Reply
#17
You won't be able to send Keep-Alive, which is what indicates a persistent connection. Well, you can, but the HTTP client is going to close the connection after the call, so it won't make any difference one way or another. It won't create a persistent connection. That just tells the server, I'd like a persisten connection if you will let me, and the server can reply that it is going to allow that and will keep it open. Then it stays open until one side drops it (or it's timed out by lack of use.)
Dean Roddey
Explorans limites defectum
Reply
#18
Dean Roddey Wrote:You won't be able to send Keep-Alive, which is what indicates a persistent connection. Well, you can, but the HTTP client is going to close the connection after the call, so it won't make any difference one way or another. It won't create a persistent connection. That just tells the server, I'd like a persisten connection if you will let me, and the server can reply that it is going to allow that and will keep it open. Then it stays open until one side drops it (or it's timed out by lack of use.)

I don't think it needs a persistent connection - the REST API is all request/response. It may just be a bit inefficient.
Reply
#19
Well, I duplicated the headers that the browser was sending so the request is exactly the same except for specifying HTTP 1.1 and the server immediately closes the connection.

I used another tool to make the request and it works same as the browser so at this point I don't think I can use the HTTPClient class to do this which is irritating because this should have been relatively easy.

I guess the next thing is to try and send data myself over a socket, but not looking forward to writing an HTTP Client...
Reply
#20
It's worse than that, you'd have to do an SSL enabled HTTP client, which you can't do in CML. Did the other tool also do a 1.1 persistent connection?
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  4.5.20 autogen calendar questions... this is just a curiusity thing...no issue per se SomeWhatLost 3 2,454 10-13-2014, 08:00 PM
Last Post: Dean Roddey
  Auto-Gen Issue Two finish.06 9 3,608 08-26-2014, 08:08 AM
Last Post: Dean Roddey
  Auto Gen Issue DaveB 6 2,920 08-22-2014, 07:36 AM
Last Post: dgilpin
  916 and 920 calc issue bbrendon 9 3,692 04-07-2013, 09:51 PM
Last Post: Dean Roddey
  918 AutoGen Issue Bugman 18 6,602 04-05-2013, 12:37 PM
Last Post: Bugman
  Timed field issue karenlee 6 2,852 02-21-2013, 03:47 AM
Last Post: karenlee
  3.3.6 driver issue rm1759 2 2,829 08-16-2010, 11:31 AM
Last Post: rm1759
  LAST issue I've found with Zoomplayer Roscoe62 0 1,760 05-03-2009, 12:31 AM
Last Post: Roscoe62
  2.0.11 IV issue, well maybe... might be something else... SomeWhatLost 11 5,564 01-27-2007, 01:42 PM
Last Post: Dean Roddey
  2.2.7 Theatertek driver issue I am having 0 581 Less than 1 minute ago
Last Post:

Forum Jump:


Users browsing this thread: 1 Guest(s)