Should this also accept a function, similar to st.Page? Doesn't necessarily need to/don't see a super strong use case but would be nice a) to be consistent and b) for small toy apps, if you just want to try this out.

Our current runtime setup requires a (main) script path; supporting a function here as well might require quite a bit of refactoring. This is probably something to track as a follow-up.

Should we explicitly add these parameters here or just have **kwargs that we pass on to the Starlette object? If we list the params explicitly, what happens if Starlette changes something? Or is that unlikely since it's such a fundamental API?

Or is that unlikely since it's such a fundamental API?

I would probably lean towards keeping it explicit since it seems quite unlikely to expect changes on the Starlette side anytime soon. The only change in the last 7 years was the deprecation of on_startup and on_shutdown in favour of lifespan. Btw. FastAPI is also explicitly exposing all the Starlette parameters in addition to the parameters relevant for FastAPI.

This is very cool. Since it's just using streamlit run then, does that mean it would also work on Community Cloud and potentially SiS?

Since it's just using streamlit run then, does that mean it would also work on Community Cloud and potentially SiS?

Yes, it's expected to work on Community Cloud and SiS as well. But some aspects might be blocked by the proxy setup. That's something to determine through manual testing.

Awesome, yeah we should definitely test that out! Lmk if you have results.

Small clarification: Do I need to do app = st.App(...) for the auto-detection to work, or can I also simply do st.App(...) without assigning it to a variable, or name that variable differently?

I think we can support both; we just need a way to "detect" that without actually running the script (e.g., regex matching or AST parsing).

OK sounds good, yeah either way is fine I think, should just document it clearly.

Is there also a way to trigger the cookie setting from within the app? Or is this always just getting set when the server starts, or on every request?

Setting a cookie from within an app session isn't possible with this since it requires JavaScript execution on the client-side. However, dynamically writing cookies is also a bit of an anti-pattern -> usage of local storage is usually the correct solution in most of those cases.

I think we need to better understand the main use cases behind #861, but some of the use cases where cookies actually make sense can be solved by setting it on a request basis and using st.context.cookies in the app session.

Can this also be run with streamlit run? I guess not, because it doesn't contain an st.App object, right?

We could theoretically support any Starlette object within the main script, since streamlit run is just a lightweight wrapper around Uvicorn to start an ASGI server. Which would also mean that you can fastapi app without any Streamlit endpoint with streamlit run

Interesting. We should just make sure there's no way to abuse this on Community Cloud. Even though it's probably fine if a few people host FastAPI apps there, as long as it doesn't become a regular pattern.

So I guess this means if an st.App instance is found, it will just run that script once and not rerun it in any way, right? Only the script passed to the script_path parameter is rerun in the normal Streamlit way, right?

Also, how does this work during development? If I change the script containing st.App, will the app automatically reload/rerun when I'm changing the script?

So I guess this means if an st.App instance is found, it will just run that script once and not rerun it in any way, right? Only the script passed to the script_path parameter is rerun in the normal Streamlit way, right?

yep 👍

Also, how does this work during development? If I change the script containing st.App, will the app automatically reload/rerun when I'm changing the script?

This will need some more investigation, but uvicorn also has auto-reloading capabilities that could be used for changes to the st.App script.

The phrase "whats relevant" is missing an apostrophe. It should be "what's relevant".

The middleware implementation will lose duplicate HTTP headers. Converting headers from ASGI's list-of-tuples format [(b'name', b'value'), ...] to a dict and back will drop duplicate header names, which are valid in HTTP (e.g., multiple Set-Cookie headers). This will break applications that set multiple headers with the same name.

# Fix: Directly append to the list instead of dict conversion
async def send_with_headers(message):
    if message["type"] == "http.response.start":
        headers = list(message.get("headers", []))
        headers.extend([
            (b"x-frame-options", b"SAMEORIGIN"),
            (b"x-content-type-options", b"nosniff"),
            (b"strict-transport-security", b"max-age=31536000"),
            (b"content-security-policy", b"default-src 'self'")
        ])
        message["headers"] = headers
    await send(message)

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.

Grammar error: "will already added in" should be "will already be added in" or "already added in".

# Current:
| No new dependencies | ✅ will already added in Starlette migration |

# Fixed:
| No new dependencies | ✅ will already be added in Starlette migration |

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.