Hello, I’m using eventstore:21.10.2-bionic docker image and trying to setup access to webui via reverse proxy. Unfortunately can’t get X-Forwarded-Prefix header to work for me 
Other headers are working. Any idea?
I think in my example response should look like
“Location: https://my_host:888/my_prefix/web/index.html”
but prefix is missing in respone.
eventstore@eventstoredb:/opt/eventstore$ curl -i -H “X-Forwarded-Prefix: my_prefix” -H “X-Forwarded-Host: my_host” -H “X-Forwarded-Port:888” -H “X-Forwarded-Proto:https” http://localhost:2113/
HTTP/1.1 302 Found
Date: Fri, 29 Apr 2022 11:02:34 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 5
Location: https://my_host:888/web/index.html
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-Forwarded-Host, X-Forwarded-Prefix, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, ES-RequireMaster, ES-RequireLeader, ES-HardDelete, ES-ResolveLinkTos
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ES-Position, ES-CurrentVersion
Regards.
- we’re not really advising to put a reverse proxy in front of the database.
- Quick question:
I see
-
https://my_host:888 is the reverse proxy doing TLS termination ?
- if not
http://localhost:2113/ should be httpS://localhost:2113
a copy if the configuration will help as well
“https://” here is to prove that “X-Forwarded-Proto:https” is working. curl is sending query via “http://”.
I’m using reverse proxy for developers to access UI.
My compose file:
eventstoredb:
image: eventstore/eventstore:21.10.2-bionic
hostname: eventstoredb
container_name: eventstoredb
environment:
EVENTSTORE_CLUSTER_SIZE: “1”
EVENTSTORE_RUN_PROJECTIONS: “All”
EVENTSTORE_START_STANDARD_PROJECTIONS: “true”
EVENTSTORE_EXT_TCP_PORT: “1113”
EVENTSTORE_HTTP_PORT: “2113”
EVENTSTORE_LOG_LEVEL: “verbose”
EVENTSTORE_LOG_HTTP_REQUESTS: “true”
EVENTSTORE_INSECURE: “true”
EVENTSTORE_ENABLE_EXTERNAL_TCP: “true”
EVENTSTORE_ENABLE_ATOM_PUB_OVER_HTTP: “true”
you need to expose the port , and this does not need a reverse proxy
see here for a minimal compose file ( single node , insecure mode ) :
I’m using curl in eventstoredb container itself, it is not an network connection issue.
Why not curl -i http://localhost:2113 then ?
Again , putting a reverse proxy in front of the DB is not recommended
I understand that the thread you’re referring to is a year old, but the issue you’re facing with setting up a reverse proxy for EventStoreDB’s web interface can still be relevant today. Technology evolves, but core concepts like reverse proxy configurations tend to remain consistent.
Given that the thread is a year old, it’s possible that there have been updates or new solutions introduced for EventStoreDB. You can also explore using a reliable proxy service, which may have advanced features and support that could simplify the reverse proxy configuration for you.
While the thread may be older, the community and the software itself often continue to address and improve common issues like this one.
You can put a proxy in front ,
It is not recommened because most believe it needs to act as a load balancer.
There is some additional configuration needed (Networking | EventStoreDB Documentation)
That begins to enter some deeper networking configuration that in my experience is not necessary most of the time and is, in production systems out there, rarely used .
It won’t be relevant with the new UI as it has its own BFF, which connects to the cluster. You’d be able to put a rev proxy in front of the new UI container if you want to. I don’t have the exact dates when it will be out to try, we currently focus on releasing it as a desktop app.
You know, I’m kinda new to this forum, just dipping my toes into the tech pool, but I’ve been tinkering with similar setups lately. It’s intriguing how these little configurations can either make your day or leave you scratching your head. Regarding your X-Forwarded-Prefix, have you checked if there’s maybe a config option or a tweak in the setup that’s slipping under the radar? Also, quick thought—could it be something to do with how your reverse proxy is handling the request? Sometimes, those 4G/LTE/5G mobile proxy can throw in a curveball or two with headers. They’re like the wild cards of the networking world, you know? Just a hunch.