Forums

I've noticed quite often after several days of no traffic that my basic Flask app seems to require a "wake-up" request before the app will respond. I have a basic GET URL that functions as a simple ping, and I often need to hit that twice (usually just a curl from the shell) before my POST URL will function properly. The first GET request simply returns nothing (not even an error). The second one returns the hard-coded string, after which the POST works.

Any suggestions?

Hmm, that's odd. If it's inactive for several days it will get shut down, but it should start up again within a few seconds when it's hit again -- at the very least, within 20 seconds (unless you have some heavyweight stuff running on web app startup).

So, just to check -- is the status code on the first GET request a 200? (Use curl's -v flag to see the status code and related header information.)

OK, I hit it after a day of no traffic, and I got a 302 on the first request (after about a 7s delay):

• Rebuilt URL to: http://kklobe.pythonanywhere.com/
• Hostname was NOT found in DNS cache
• Trying 50.19.109.98...
• Connected to kklobe.pythonanywhere.com (50.19.109.98) port 80 (#0)

  GET / HTTP/1.1 User-Agent: curl/7.37.1 Host: kklobe.pythonanywhere.com Accept: /

  < HTTP/1.1 302 FOUND

• Server ngx_openresty/1.4.3.6 is not blacklisted < Server: ngx_openresty/1.4.3.6 < Date: Wed, 10 Dec 2014 01:53:09 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Vary: Cookie < Location: http://kklobe.pythonanywhere.com/ < Set-Cookie: sessionid=4ad3b351c7201d765552453242506cad; expires=Wed, 24-Dec-2014 01:53:09 GMT; Max-Age=1209600; Path=/ <
• Connection #0 to host kklobe.pythonanywhere.com left intact

The second request worked fine:

< Date: Wed, 10 Dec 2014 01:53:09 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Vary: Cookie < Location: http://kklobe.pythonanywhere.com/ < Set-Cookie: sessionid=4ad3b351c7201d765552453242506cad; expires=Wed, 24-Dec-2014 01:53:09 GMT; Max-Age=1209600; Path=/ < * Connection #0 to host kklobe.pythonanywhere.com left intact

• Rebuilt URL to: http://kklobe.pythonanywhere.com/
• Hostname was NOT found in DNS cache
• Trying 50.19.109.98...
• Connected to kklobe.pythonanywhere.com (50.19.109.98) port 80 (#0)

  GET / HTTP/1.1 User-Agent: curl/7.37.1 Host: kklobe.pythonanywhere.com Accept: /

  < HTTP/1.1 200 OK

• Server ngx_openresty/1.4.3.6 is not blacklisted < Server: ngx_openresty/1.4.3.6 < Date: Wed, 10 Dec 2014 01:55:05 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 13 < Connection: keep-alive <
• Connection #0 to host kklobe.pythonanywhere.com left intact Hello, world!

Hi there,

We do spin down webapps after a period of inactivity (26 hours if memory serves). However they should spin right back up on the first new hit, in such a way that no request is ever lost, although that first hit may take a few seconds.

The 302 is a redirect code (https://en.wikipedia.org/wiki/HTTP_302). Web browsers follow redirects automatically, so if you'd done that hit in a web browser, all you'd have noticed is the site taking a few seconds to load, but it would have loaded normally.

I'm not sure what you're using for your tests, but (unlike web browsers) many libraries require an additional command to follow redirects. for curl it's -L for example...

So that, at least, is the theory! You say you have a POST url that's not behaving correctly? What are you using to POST to it?

Yep, I'm aware that 302 is a redirect, I just wasn't expecting it since I only get it on the first hit after the spin down.

I'm using .NET's HttpClient.PostAsync() (on Xamarin.iOS, specifically) to do the POST, as well as curl for testing. Now that I know to expect a redirect, I can just throw logic in to always check for the 302 and retry.

Thanks!

EDIT: P.S. I have seen several times where the browser doesn't redirect on the first hit as well; I get a completely blank page (using OS X Safari). Hitting refresh then shows the string.

OK -- let us know if you ever see anything unexpected from the POST calls. We'll take a look and see if we can figure out why it might intermittently fail... If you do see ever see a blank page like that again, can you send us a dump of the page source and the headers (if you have access to them?)