Compression not working on Railway, works on Local
I have a Python web app that uses a compression middleware. The middleware supports Brotli and uses Gzip as a fallback. The responses are correctly compressed on my local machine, but when serving over Railway, they are served uncompressed.
Solution:Jump to solution
Railway's proxy does not currently support proxying compressed requests and responses.
25 Replies
Project ID:
34108dc5-7795-469f-b853-2863bbedfa6f34108dc5-7795-469f-b853-2863bbedfa6f
Solution
Railway's proxy does not currently support proxying compressed requests and responses.
Not sure I understand. I found this related thread and they were using Brotli
https://discord.com/channels/713503345364697088/1272009731233284177
yep, it was enabled and then decided later to be disabled again
Oh. Is there an ETA to enable it again?
This affects user experience and egress costs
we don't currently have any immediate plans that I'm aware of to enable this at the proxy level
when enabled our proxy has to do the compression and decompression for every request.
Was this announced? It's an important feature to support, compression would reduce my responses by ~80%
it was not announced
It has SEO implications too
I'm sorry but it wasn't economical for us, in the future we may look into allowing the user's server and client do the compression instead of our proxy.
Ok, please bubble this up to the powers that be. I really love using railway, but I'm going to have to test some other service providers now
for context a beloved ex railway employee has asked for it, so we will likely be giving it a serious thought
Thanks. I really hope you guys can add back the support. Performance is important for me and my users
Will it help if I write a note in the
feedback channel?if we do add it back, it wouldn't be at the proxy level, your server and client would be responsible for compression.
Does that just mean I bear the CPU cost? Or are there other tradeoffs?
that's correct
no need for a new thread, you can bump this thread - https://help.railway.app/questions/new-proxy-stripping-accept-encoding-head-56fb16a0
the rest of the team will be back at work Tuesday, so expect some kind of answer there by EOW
Perfect, thank you sir
no problem, going to solve this, please bring further discussion to that linked thread.
New reply sent from Help Station thread:
Brody, just to get it right, does this mean that even though my client is sending the correct Accept-encoding headers and I have a compression middleware in my nodejs server, the response won't be delivered as compressed? I'm experiencing the same issue where the response gets correctly compressed when running my nodejs server locally, but when deployed in Railway the compression doesn't work nor the Content-Encoding header is present. I'm not using any reverse proxy. Just the Nestjs server, with the compression middleware. Is there a work around for this? Thanks in advance.You're seeing this because this thread has been automatically linked to the Help Station thread.
that's correct, compression is disabled at the proxy level
New reply sent from Help Station thread:
Thanks for the response, Brody. Is there any workaround for this? Is there any way that I can deploy my server on Railway and still be able to use compression for just the common uses of json, text or scripts?You're seeing this because this thread has been automatically linked to the Help Station thread.
as it has been disabled at the proxy level there would be no workaround.
please bump the linked thread made by greg.
@Railay - we have pushed a change, as long as your server code and client support compression, your responses will be compressed
Thanks! I’ll check it out when I get home
read more about it here - https://railway.app/changelog/2024-09-06-edge-improvements#edge-network-improvements