Option to disable real-time SSE-based loading page (per container maybe) #124

Closed
opened 2025-12-29 09:23:25 +01:00 by adam · 13 comments
Owner

Originally created by @crgmz on GitHub (Dec 17, 2025).

Hello, is there a way to disable the loading page that shows while a container is waking up? I have some apps hitting my container that error out when they receive html (the loading page) because they expected json. An option to not respond to the request until the container is ready would be great as the container I'm running only takes a few seconds to wake up

Originally created by @crgmz on GitHub (Dec 17, 2025). Hello, is there a way to disable the loading page that shows while a container is waking up? I have some apps hitting my container that error out when they receive html (the loading page) because they expected json. An option to not respond to the request until the container is ready would be great as the container I'm running only takes a few seconds to wake up
adam closed this issue 2025-12-29 09:23:25 +01:00
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

GoDoxy does not send HTML loading page but instead a plain "Container woken" response for non HTML-requests.

I've just added back an old logic which wait and redirect until the container is ready (b7250b29e0).

If it still does not work, I've also added an option to disable loading page per container (86a46d191d).

Please either try it on nightly tag or wait for the next patch v0.21.1.

@yusing commented on GitHub (Dec 17, 2025): GoDoxy does not send HTML loading page but instead a plain "Container woken" response for non HTML-requests. I've just added back an old logic which wait and redirect until the container is ready (b7250b29e08968678c9ffd937d0e3bf84246a30a). If it still does not work, I've also added an option to disable loading page per container (86a46d191d7e2624519bd3d40c36258caa5f9cd2). Please either try it on `nightly` tag or wait for the next patch v0.21.1.
Author
Owner

@crgmz commented on GitHub (Dec 17, 2025):

Thank you so much for the quick response, I appreciate it. I just tested the nightly image and have one tiny question: I see you chose http.StatusSeeOther (303) for the redirect which tells the client to handle the redirect with GET (as per mdn), that unfortunately breaks endpoints that didn't expect or explicitly disallow GET (as I found out from testing just now). Any reason to go with 303 instead of 307?

@crgmz commented on GitHub (Dec 17, 2025): Thank you so much for the quick response, I appreciate it. I just tested the nightly image and have one tiny question: I see you chose `http.StatusSeeOther` (303) for the redirect which tells the client to handle the redirect with `GET` (as per [mdn](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/303)), that unfortunately breaks endpoints that didn't expect or explicitly disallow `GET` (as I found out from testing just now). Any reason to go with 303 instead of 307?
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

You're right, 307 should be used. Just curious what is use case of sending a POST/PUT request to a sleeping service?

Edit: the redirection is unnecessary, changed to serve the request directly instead

@yusing commented on GitHub (Dec 17, 2025): You're right, 307 should be used. Just curious what is use case of sending a POST/PUT request to a sleeping service? Edit: the redirection is unnecessary, changed to serve the request directly instead
Author
Owner

@crgmz commented on GitHub (Dec 17, 2025):

in my case the POST contains a payload that describes some jobs for the service to execute

@crgmz commented on GitHub (Dec 17, 2025): in my case the `POST` contains a payload that describes some jobs for the service to execute
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

I see. Please update the nightly iamge and try again

@yusing commented on GitHub (Dec 17, 2025): I see. Please update the nightly iamge and try again
Author
Owner

@crgmz commented on GitHub (Dec 17, 2025):

I just tested the new nightly and I think the redirect is needed, without it the first request to a sleeping service (GET, POST, anything) returns 502 while the service wakes up.

@crgmz commented on GitHub (Dec 17, 2025): I just tested the new nightly and I think the redirect is needed, without it the first request to a sleeping service (`GET`, `POST`, anything) returns 502 while the service wakes up.
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

I don't think adding redirect will help. The cause is health checker does not treat 5xx (execept 503) as "unhealthy" as stated in https://docs.godoxy.dev/Health-monitoring#http-healthcheck.

We should add 502 and 504, or even all 5xx code. What do you think?

@yusing commented on GitHub (Dec 17, 2025): I don't think adding redirect will help. The cause is health checker does not treat 5xx (execept 503) as "unhealthy" as stated in https://docs.godoxy.dev/Health-monitoring#http-healthcheck. We should add 502 and 504, or even all 5xx code. What do you think?
Author
Owner

@crgmz commented on GitHub (Dec 17, 2025):

The redirect provided a nice (and maybe unintended) built-in retry as the client simply followed the redirect until the service was ready (a few seconds in my case), without it I'm stuck with 3rd-party clients that don't have any custom retry logic and stop dead in their tracks as soon as the 502 comes in (and an error page when loading the website of a sleeping service). I'm starting to feel like I'm the spacebar heating guy, but the redirect with a 307 would be nice for my usecase, I would even settle for the original 303 as that allowed GET requests to work nicely in the browser

@crgmz commented on GitHub (Dec 17, 2025): The redirect provided a nice (and maybe unintended) built-in retry as the client simply followed the redirect until the service was ready (a few seconds in my case), without it I'm stuck with 3rd-party clients that don't have any custom retry logic and stop dead in their tracks as soon as the 502 comes in (and an error page when loading the website of a sleeping service). I'm starting to feel like I'm the [spacebar heating](https://www.explainxkcd.com/wiki/index.php/1172:_Workflow) guy, but the redirect with a 307 would be nice for my usecase, I would even settle for the original 303 as that allowed `GET` requests to work nicely in the browser
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

I see your point. Adding 5xx code to health check logic will cause the waitReady method it wait until it sees non-5xx, and then proceed to the upstream. So you won't see 5xx on the client side. Talking is cheap, let me do the commit and you can test it with another update.

@yusing commented on GitHub (Dec 17, 2025): I see your point. Adding 5xx code to health check logic will cause the `waitReady` method it wait until it sees non-5xx, and then proceed to the upstream. So you won't see 5xx on the client side. Talking is cheap, let me do the commit and you can test it with another update.
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

Updated, try again?

@yusing commented on GitHub (Dec 17, 2025): Updated, try again?
Author
Owner

@crgmz commented on GitHub (Dec 17, 2025):

yup, that did it, thank you very much

@crgmz commented on GitHub (Dec 17, 2025): yup, that did it, thank you very much
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

Great. That should be it. Will release together with another bug fix.

@yusing commented on GitHub (Dec 17, 2025): Great. That should be it. Will release together with another bug fix.
Author
Owner

@yusing commented on GitHub (Dec 17, 2025):

Closing it now as fixed in 0.21.1

@yusing commented on GitHub (Dec 17, 2025): Closing it now as fixed in 0.21.1
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/godoxy#124