Timeout ESP-13 ESP8266 Timeout for specific endpoint

Hi All,

I am using the Espruino Board (not Pico) : Firmware 1.87 (updated to 1.89 but have not retested yet)
I have not got to the bottom to why my ESP-13 ESP8266 is sensitive to this specific URL and putting this out to you chaps hopefully someone might flag something that I have not considered.

If you put the address in your browser:

https://preview.gamesparks.net/callback/295737vYb5Kd/lamp/kPFrmFnPWrdJuJ69M4DimgXxuhrVRefx/572a4047808eb904a08d149c

you will see the result {"lightResponse":"572a4047808eb904a08d149c"}

My ESP13 will work perfectly for all URLs I have tried via HTTPS/HTTP requests via the request("http").get() api. However calling the above end point will throw a timeout error which makes it seem there is something specific to the host (request time, headers required, cookies needed)

require("http").get("https://preview.gamesparks.net/callback/295737vYb5Kd/lamp/kPFrmFnPWrdJuJ69M4DimgXxuhrVRefx/572a4047808eb904a08d149c", function(res) {
				        console.log("Response: ",res);
				        res.on('data', function(d) {
				          console.log("--->"+d);
		                 
				        });
				      });
			

 at line 1 col 52
throw Error("CIPSTART failed ("+(a?a:"Timeout")+")");

I have only really seen Olli have this error with Key signing for TLS. TLS is only available via Pico and I can call other HTTPS endpoints so have to assume certs signing is not the issue (well I will conveniently ignore this potential as I don't have root access to the SaaS being called) :)
http://forum.espruino.com/conversations/293351/

I think I need to isolate a couple of things:

1. Is the issue specific to my ESP13? (unlikely) -- It would be great if someone could call the callback request above from their ESP and see if they get a timeout via http get()
   
2. Is the request timeout for request("http") configurable?
   
3. Is this an issue because I am using the Espruino Board with HTTPS and not the Pico?
   
   

I have tried writing custom headers passing user agent and cookie etc with no success.

hmm, any ideas?

Thanks everyone

Fraser

Hi. ESP8266 is any incarnation isn't an Espruino board. They comprise "original", "Pico" and the latest "Wifi" boards. Anything else is unofficial including your ESP13.

TLS is available on the Wifi board as well as Pico. I think that's just a matter of the docs lagging behind the development.

I don't think the ESP8266/ESp13 will have enough room to store (1700 JSVars) the certs and keys to get you a TLS connection, but Espruino Wifi is a good bet.

Sorry Ollie I did post this is the wrong place by accident but good info you have provided.
Can't seem to move the post so it will have to stay I guess.

TLS does not seem to be on the "original" which I am using (does not identify the module through require). My ESP13 I'm not looking to add Espruino on-board (posted without reading the section name properly); just running it off the USRT serials.

Now that you're here... :) Are you able to request this URL via HTTP Get via your ESP?

https://preview.gam­esparks.net/callback/295737vYb5Kd/lamp/k­PFrmFnPWrdJuJ69M4DimgXxuhrVRefx/572a4047­808eb904a08d149c

Does it resolve or timeout for you?

Don't worry if you are busy -- I'm just hoping by deduction I will find out why my ESP13 throws a timeout error for this URL.

Cheers

Ah, ok got it. The placement confused me and will others. @Gordon will move it for you.

If I had access to my Espruino Wifi I'd gladly test that for you, but I don't at moment. I can maybe test tomorrow for you.

Re that URL... if you hit https:// in a web browser it returns, but if you attempt http:// it does not respond and I guess it will timeout. That would seem to be inline with what you are seeing given you can't call the https endpoint? It looks they've not implemented a HTTP service/listener or redirection to https://, at least not for that endpoint.

The formatting has stripped the https:// -- Gone back and code encapsulated

https://preview.gamesparks.net/callback/­295737vYb5Kd/lamp/kPFrmFnPWrdJuJ69M4Dimg­XxuhrVRefx/572a4047808eb904a08d149c

The request is only available via https (not trying to call http)
I can call other https endpoints no problem from the Espruino Original & ESP13. Just this URL fails on the ESP which is making the failure hard to debug (does not fail via node, Curl, browser etc)

Only the ESP has an issue on this specific domain which is why I wondered if there was any response timeout settings that could be tweaked via the Espruino request API?

The server is using SNI. You'll need to send a 'host' option, which is part of the TLSConfig, I don't think you can resolve this URL without that.

Ollie :) :) I think you are on to it! I was hoping for a little nugget like this from someone to send me down the correct avenue (I did send host value I think when I built custom headers but worth another look). I will set it up again this evening when I get in and let you know how it goes. Great spot thanks

Hi - sorry - only just spotted this here. I'll move it now.

But as Ollie has said, it looks like the site only does HTTPS. Since the original Espruino doesn't have enough memory for HTTPS, I think it just ignores the https:// and tries with HTTP anyway - which is probably why you get the timeout?

Just gonna do some self-endorsement here, you could try using HttpToHttps like in this post.

Thanks for the replies and thanks for moving this over Gordon. I have been busy so only just got back to the investigation.

So I tried to call to the SNI spec as Ollie suggested and this didn't work giving the same timeout exception was thrown -- Code below just in case others find this format useful

require("http").get({
                        host: 'https://preview.gamesparks.net',
				        path: '/callback/295737vYb5Kd/lamp/kPFrmFnPWrdJuJ69M4DimgXxuhrVRefx/572a4047808eb904a08d149c'
				    }, function(response) {
				    	 console.log("Response: ",response);
				        var body = '';
					        response.on('data', function(d) {
					            body += d;
					        });   


					     }

Gordon you are correct in the fact I was recording a false positive by loading a text file to my secure domain and not realising the Expruino was just sending HTTP.

I have a few Pico's but prefer the original espruino as my project uses more USART's than the Pico has available.

Good to clarify there is no way the Original Board can do HTTPS

Happy you are getting there.

@Gordon so when you ask for a HTTPS resource via Espruino, your request can fallback onto HTTP if board doesn't support HTTPS, and you may not know about it?

I don't think this is best approach personally - lot of sites running both services currently whilst trying to transition to TLS.

Yes - on boards without HTTPS, all the code that checks the protocol is removed and it always uses HTTP - it behaves just like an Espruino board did before HTTPS support was added.

Someone could issue a PR if they wanted that re-added just the HTTPS check and made it cause an error if they wanted.