+1 for adding back support for compression. This is an important feature for user performance and SEO.

Hey Greg and thank you so much for calling this out!

Mig, one of our infrastructure team members is aware and will be looking into not stripping those headers

Thank you 🙏🏼

AAAAAAaaaaaaaarrrrggg, I finally understand why I'm struggling for hours!

At least my project's configuration is now ready to handle encoding

Hello all, we have pushed a change to our proxy, we no longer strip out that header!

https://railway.app/changelog/2024-09-06-edge-improvements#edge-network-improvements

AMAZING NEWS!!!! I'm impressed with the fast response and solution. I was about to migrate everything to Azure or GCP just because of that header. I'll stay in Railway now

Thanks for the quick turnaround

Hello all, we have pushed a change to our proxy, we no longer strip out that header!

https://railway.app/changelog/2024-09-06-edge-improvements#edge-network-improvements

The changelog mentions "we previously handled this for you," though I don't think this was true. The header was stripped and an uncompressed response was returned.

It would actually be useful if Railway compressed responses when requested with Accept-Encoding. Cloudflare does this [0] and it's nice, since it can be a pain to do it in middleware

[0]: https://developers.cloudflare.com/speed/optimization/content/brotli/content-compression/

The changelog mentions "we previously handled this for you," though I don't think this was true. The header was stripped and an uncompressed response was returned.

It was supported for a short while but we ended up disabling it because of memory spikes on the proxy hosts. Wasn't the quick win we thought it would be :D

We definitely want to do this though - going to track this feedback in a separate thread here: https://help.railway.app/feedback/v2-proxy-support-compression-e4d7eee6