404 health check when navigating directly to a subpage

[Raytray]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

On multiple page applications, when navigating directly to a subpage, the healthcheck and allowed message origins check is issued twice.
https://doc-mpa-hello.streamlit.app/Mapping_Demo?utm_medium=oembed page will receive 404 on the following
https://doc-mpa-hello.streamlit.app/~/+/Mapping_Demo/_stcore/health
https://doc-mpa-hello.streamlit.app/~/+/Mapping_Demo/_stcore/allowed-message-origins
and 200 OK on
https://doc-mpa-hello.streamlit.app/~/+/_stcore/health
https://doc-mpa-hello.streamlit.app/~/+/_stcore/allowed-message-origins

Reproducible Code Example

No response

Steps To Reproduce

1. Go to https://doc-mpa-hello.streamlit.app/Mapping_Demo?utm_medium=oembed with the network inspector open
2. Review the _stcore network calls made

Expected Behavior

Expected to only see the 200 OK requests and those 404 requests to never be made.

Current Behavior

Currently see two 404 requests and two 200 requests.

404 on the following
https://doc-mpa-hello.streamlit.app/~/+/Mapping_Demo/_stcore/health
https://doc-mpa-hello.streamlit.app/~/+/Mapping_Demo/_stcore/allowed-message-origins
and 200 OK on
https://doc-mpa-hello.streamlit.app/~/+/_stcore/health
https://doc-mpa-hello.streamlit.app/~/+/_stcore/allowed-message-origins

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

No response

Additional Information

Maybe solved by making these two consts tied to the root and not relative?

streamlit/frontend/app/src/connection/WebsocketConnection.tsx

Lines 48 to 53 in d6d8f62

	const SERVER_PING_PATH = "_stcore/health"
	/**
	* The path to fetch the whitelist for accepting cross-origin messages.
	*/
	const ALLOWED_ORIGINS_PATH = "_stcore/allowed-message-origins"

[vdonato]

Hey @Raytray, thanks for reporting this!

This is behavior that's known but unfortunately a bit tricky to fix. The main difficulty is that making these endpoint calls tied to the root can be hard as it's not always entirely clear what the root of an app is in every deployment scenario.

For example, a Streamlit app being served behind a reverse proxy (that may be transparent to the streamlit server/client) with root at https://example.com/foo/bar and page bar of an app being served at https://example.com/foo initially look identical to the web client. We could probably solve this by including the paths to all pages of an app in the index.html so that we can determine when an initial request is being made to a subpage and change where we send the initial healthchecks accordingly , but it'd be a decent amount of work to do for what I think is a relatively small improvement and thus lands pretty far down the backlog. (There are some edge cases around this too like if an app served at https://example.com/foo/bar has subpage bar. I feel like these are contrived enough that we'd be okay with just accepting the weird behavior for these, though)

Of course, if we have enough people complaining that this additional 404 when navigating directly to a subpage is a huge issue for their apps, we can bump up the priority on this.

[dsblank]

What are the consequences of the 404s? Is there a loss of functionality? If not, why are these endpoints called to begin with?

I'm trying to track down badly behaving subpages, and hope to rule out these 404s.

[akertconsulting]

This ends up causing pages to refresh constantly due to those 404s.
So if someone submitted something on the page and gets results due to it, it ends up being wiped out after 30 seconds. We're having a lot of difficulty with it today.

Is there any workaround? Other than making sure people don't navigate straight to a sub-page?

[giacomochiarella]

we are actually having bad user experience due to 400 on {page}/_stcore/health. It happens sometimes (like when it is redeployed or after some expiration date) that when the website is open it infinitely tries to call wss://<>/{page}/_stcore/health which of course gives 404. This loop stays forever. To solve it I need to clear browser data. Would be great to have a solution.
https://<>/_stcore/health is reachable instead, no issues

[giacomochiarella]

I can see also that the content of _stcore/host-config is
{"allowedOrigins": ["https://devel.streamlit.test", "https://*.streamlit.apptest", "https://*.streamlitapp.test", "https://*.streamlitapp.com", "https://share.streamlit.io", "https://share-demo.streamlit.io", "https://share-head.streamlit.io", "https://share-staging.streamlit.io", "https://*.demo.streamlit.run", "https://*.head.streamlit.run", "https://*.staging.streamlit.run", "https://*.streamlit.run", "https://*.demo.streamlit.app", "https://*.head.streamlit.app", "https://*.staging.streamlit.app", "https://*.streamlit.app"], "useExternalAuthToken": false, "enableCustomParentMessages": false}
is it possible to remove all these addresses for security reason and avoid to call _stcore/host-config? A solution to the issue could be if we can configure this host-config and maybe set the health url via parameter

[giacomochiarella]

we have deployed streamlit in ecs task behind a load balancer. Is it enough to open only 443 port? I would say yes give that it works in a freshly open browser but then it gets stuck on 400 on wss if streamlit is redeployed

[giacomochiarella]

Firefox can’t establish a connection to the server at wss://<>/stream. [main.ca9076db.js:2:4351407](https://<>/static/js/main.ca9076db.js)
The connection to wss://<>/stream was interrupted while the page was loading.

the response is a 400 bad request

[zoltan-spire]

It might be the same root cause that prevents my app to load static files when (including main.js) when the user refreshes a page with browser refresh.

GET http://localhost:8502/Downlink%20Q1/static/media/SourceSansPro-Regular.0d69e5ff5e92ac64a0c9.woff2 net::ERR_ABORTED 404 (Not Found)
GET http://localhost:8502/Downlink%20Q1/static/media/SourceSansPro-SemiBold.abed79cd0df1827e18cf.woff2 net::ERR_ABORTED 404 (Not Found)
GET http://localhost:8502/Downlink%20Q1/static/media/SourceSansPro-Bold.118dea98980e20a81ced.woff2 net::ERR_ABORTED 404 (Not Found)
GET http://localhost:8502/Downlink%20Q1/static/css/main.77d1c464.css net::ERR_ABORTED 404 (Not Found)
GET http://localhost:8502/Downlink%20Q1/static/js/main.1661a802.js net::ERR_ABORTED 404 (Not Found)
GET http://localhost:8502/Downlink%20Q1/favicon.png 404 (Not Found)

I am not sure why is this issue just popped up, but it used to work fine, and in fact, on other pages of the same app the static files are loaded from the correct URLs and without error:

http://localhost:8502/static/media/SourceSansPro-Regular.0d69e5ff5e92ac64a0c9.woff2
http://localhost:8502/static/media/SourceSansPro-SemiBold.abed79cd0df1827e18cf.woff2
http://localhost:8502/static/media/SourceSansPro-Bold.118dea98980e20a81ced.woff2
http://localhost:8502/static/css/main.77d1c464.css
http://localhost:8502/static/js/main.1661a802.js

If we cannot expect a fix for this bug, I would really appreciate some help how to work around the issue (I cannot tell all my users to visit the root of the app, and also cannot tell them not to use browser refresh on a page)

For context

• streamlit version: 1.33.0
• python version: 3.10.10
• using st_pages to implement multi-page app.