I’m writing an app that’s use more as a REST API and not from a browser. Having these responses sometimes be a 200 with an HTML page is adding more complications.
Hey @wh0, thanks for the suggestion. Don’t forget to vote for it yourself.
As far as this specific functionality is concerned, nothing like this is in our near-term plan. There’s a similar request at Ability to change the Waking Up/Preparing screen but I don’t think it addresses what you’re asking for. If you can describe in more detail how the current functionality is interfering with your API project, perhaps someone can suggest a useful workaround.
Here’s some info on my API project. I have a program that loads a URL from my Glitch app, which is supposed to respond with a short string.
In cases where Glitch would instead send a “Waking up” page, that response can’t be used as the short string, thus it interferes with the correct operation of the overall system.
Oh, looks like POST requests don’t go through the interstitial. Very sane, nice. I could work around it by making everything use POST requests.
Setting a content-type header also prevents the loading screen.
a content-type header on a GET request–is that legal?
It’s not illegal - spec only specifies you should provide a content type when there’s a body, but I’m just letting you know how it works.
cool, thanks!
do you know if an Accept header would also work? I feel like that would be more suitable, since I’m not sending a body with the request
We just had the same problem and the fix was setting an user-agent in the request. This skipped the “waking up” page and gave us the expected json data.
Hey there! Don’t bump old posts!
Make a new thread if you have a fix, or if you need help make a new thread requesting that!
The “waking up” screen on normal GET requests for HTML pages can be a huge problem too… for offline-capable pages (PWAs)! A ServiceWorker caching that interstitial instead of the actual app HTML is very bad