Delay to allow proxy-process readiness

[sudhaker]

trafficstars

When server is launching a relatively heavier process (like theia), then first request (open tab) almost always fails.

Proposed change

Allow a delay parameter in the configurations

Alternative options

Let _http_ready_func wait for HTTP 200 OK status ref: jupyter_server_proxy/handlers.py

Who would use this feature?

Anyone proxy-ing a relatively heavier process (like theia)

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[yuvipanda]

Thank you for opening this, @sudhaker! Does the 'timeout' option (documented under https://jupyter-server-proxy.readthedocs.io/en/latest/server-process.html#server-process-options) work for your use case? It defaults to 5 but can be increased.

[sudhaker]

No it doesn't help. The health-check loop exits the minute port is available and doesn't allow for real readiness (i.e. status 200 OK)

[sudhaker]

Any update?

[manics]

It looks like the check accepts any HTTP status: https://github.com/jupyterhub/jupyter-server-proxy/blob/ee403c608f9b92ed712576e50be4c4539ca939a7/jupyter_server_proxy/handlers.py#L473-L476

[manics]

@yuvipanda do you think it makes sense to make _http_ready_func a configurable callable?

[sudhaker]

It looks like the check accepts any HTTP status: https://github.com/jupyterhub/jupyter-server-proxy/blob/ee403c608f9b92ed712576e50be4c4539ca939a7/jupyter_server_proxy/handlers.py#L473-L476

I'm not clear about the use-case behind launching the proxied UI before the back-end service confirms the "http-200" status?

Thank you for quick response.

[manics]

My guess is it's because the check is a "dumb" http request, whereas your application may require cookies or headers to be set to return a successful status.

[sudhaker]

My guess is it's because the check is a "dumb" http request, whereas your application may require cookies or headers to be set to return a successful status.

Makes sense as 200 Ok is not always guaranteed.

Possibly we can have it a configurable list of "valid status code" as the success criteria, which can be overridden as needed.

And 200/302/401 makes a good default.

[manics]

I was thinking maybe a callable, so you could specify both the URL path and acceptable status codes.

[sudhaker]

I was thinking maybe a callable, so you could specify both the URL path and acceptable status codes.

Even better :-)

[sudhaker]

+Bump