a year ago
Issues with Making HTTPS GET Requests from ESP32 to FastAPI Server Hosted on Railway.app (Error 426)
Hello everyone,
I've been working with an ESP32 programmed in MicroPython and encountered a specific issue when attempting to make HTTPS GET requests to my FastAPI server, which is hosted on Railway.app and runs with Uvicorn. While the ESP32 can make GET requests to a wide variety of sites, both HTTP and HTTPS, without any issues, attempting a GET request to my FastAPI API on Railway results in an HTTP 426 (Upgrade Required) status code from the server.
I have verified and confirmed that the GET requests work correctly when tested from other devices and HTTP clients (such as Postman or a web browser), indicating that the issue is specifically related to requests originating from the ESP32. Additionally, the server has been tested locally and works well, which suggests that the deployment on Railway or the interaction with Railway's environment might be contributing to the issue.
Here is a summary of what I've tried:
Ensuring the ESP32's firmware is up to date and supports SSL/TLS for HTTPS connections properly.
Making requests to both HTTP and HTTPS endpoints on other domains, which work without issues, indicating the ESP32 can handle SSL/TLS.
Inspecting the requests and responses using web development tools to ensure there are no obvious issues with the headers or request content.
Testing the FastAPI server locally with Uvicorn, where it functions as expected, suggesting the issue arises specifically when hosted on Railway.
My question is as follows: Are there any known restrictions or specific configurations on Railway.app that might be causing this issue with devices like the ESP32? Is it possible that Railway is detecting incoming traffic from IoT devices and requires some form of "upgrade" or special configuration to allow these requests?
Any guidance on how to resolve this issue or where to look for more information would be greatly appreciated. I'm particularly interested in knowing if anyone else has experienced similar problems when connecting IoT devices to APIs hosted on platforms like Railway.
Thank you in advance for your help and suggestions.
3 Replies
a year ago
Railway requires all requests to be made with https version 1.1 and above with tls 1.3.
there's a good chance the http client built into micropython does not meet these requirements. I am able to reproduce the 426 status code when setting my http client (insomnia) to http 1.0
I must say, very well written question!
edit: if there's no way to get the http client in micropython to use https 1.1 and tls 1.3 you can put a proxy in front of your app, both cloudflare and fastly's proxies will accept https 1.0 and tls 1.1 traffic.
Status changed to Solved railway[bot] • about 1 year ago
a year ago
I just wanted to try to make my ESP32 Project avaliable over World Wide Web somehow.
I wanted to try to install Husarnet Client on the Railway Platform today, with a docker image running something like ->
Install Husarnet client
RUN apt-get update && apt-get install -y curl
RUN curl https://install.husarnet.com/install.sh | bash
Make port 8000 available to the world outside this container
EXPOSE 8000
I am not sure if this will work, but I am pretty much interested in making my ESP32 talk to the world outside somehow without using a relay server to handle the requests.
Currently running a husarnet framework on the ESP32 talks perfeclty to the local network and over WWW when using the husarnet client on my laptop.
Now I need to see if something like this is possible on Railway to install.
I will probably run into problems because ::
Directly installing and running the Husarnet client on Railway may face limitations due to the nature of PaaS environments, which typically abstract away the underlying operating system and network configurations, restricting deep system-level changes like installing VPN clients. This is because PaaS platforms like Railway are designed to streamline web application deployment by managing the infrastructure, runtime, and networking layers for you, which often limits the level of control you have to install custom software or modify the network stack.