AxiosError: Request failed with status code 400

[cmbkr]

I have a streamlit app which allows users to upload csv files. It is deployed on Azure running as a web app service.

When users upload a file I they get good old AxiosError: Request failed with status code 400

My config as follows;

requirements.txt

streamlit==1.31.0
python-dotenv==1.0.0
pandas==2.2.0

---

Dockerfile

FROM python:3.11-slim

WORKDIR /app

# Copy the requirements.txt file and install dependencies first
COPY requirements.txt .
RUN apt-get update && apt-get install -y \
    g++ \
    unixodbc-dev \
    curl \
    build-essential \
    software-properties-common \
    git \
    && rm -rf /var/lib/apt/lists/* \
    && pip install -r requirements.txt

# Copy the rest of your application files
COPY . .

EXPOSE 8501

# Set the entry point
ENTRYPOINT ["streamlit", "run", "app.py", "--server.enableXsrfProtection=false", "--server.enableCORS=false", "--server.port=8501"]

---

config.toml

[server]
port = 8501
enableCORS = false
maxUploadSize = 500

[browser]
serverPort = 8501

[logger]
level = "debug"

---

– Error:

[Caroline]

Hey @cmbkr,

Thanks for sharing this question. Is this happening when you upload any file or just files above a certain size?

[cmbkr]

Any file, any size

[Caroline]

This sounds like the issue described here, which is basically that the /upload endpoint used by Streamlit has its request routed to a different node than the one that the frontend is connected to (I’ll paste the longer explanation from @vdonato below too in case you’re curious).

The TDLR is that the best way to resolve this error is to enable session affinity/sticky sessions within Azure. Here’s a doc that describes where you can find this setting.

Full explanation from @vdonato:

Coincidentally, we’re currently working on a project that will eventually enable users to configure pieces of the file uploader widget so that it can operate more smoothly in multi-instance deployments. We’ve recently worked on several projects with a similar theme of making the Streamlit internals more configurable, but the piece we’re missing before we’ll be able to expose all of these things publicly is a more advanced config system. See this comment on a similar issue for more context: #5849 (comment).

That being said, even once everything is available for public use, I’d probably still recommend relying on session affinity to get st.file_uploader to work as expected in most multi-instance deployments.

The difficulty with getting a widget like the file uploader to work correctly when there are several streamlit server instances (assuming no session affinity) is that the file upload, which happens via HTTP as sending large files via websocket comes with its own set of difficulties, may land on a different server than the one the browser has a websocket connection to. As a result of this, a solution would require either

1. Streamlit servers to be able to talk to each other to pass files around

• This would require some nontrivial configuration outside of streamlit itself to enable service discovery. It also feels somewhat hacky

2. A way to upload files to a shared location (like AWS S3 or some other intermediary service) rather than directly to an individual streamlit server

• This is what the in-progress changes to the file uploader widget will enable. It feels like the more “correct” solution to me

The difficulty with both solutions is that they’re far from “automatic” – developers will have to do a nontrivial amount of work outside of Streamlit to get everything set up. While some users will certainly have use cases where it’s worth the effort to do this (including us at Snowflake, which is why we’re building this configurability into the file uploader to begin with), I’d imagine that it wouldn’t be worth the effort compared to just turning on sticky sessions in most situations.

[cmbkr]

Thank you for your help.

I have tested these options but same result.

I have created

• a web app service and configured its deployment to pull its source from the container registry
• a container web app and configured it as described
• a web app and deployed my code as raw application with different configurations in config.toml

same results!
I am puzzled, I hope some one can help!

Thank you

[Caroline]

Hey @cmbkr, just to clarify – you enabled session affinity within Azure, and you’re still seeing the same error?