[openstreetmap/openstreetmap-website] Compress plain GPX uploads with gzip (PR #7124)

Ruben L. Mendoza notifications at github.com
Mon Jun 22 16:40:13 UTC 2026


Rub21 left a comment (openstreetmap/openstreetmap-website#7124)

> Can somebody explain how GpxS3Service even gets invoked?

To actually use it, we need switch the traces storage in chef from service: "S3" to service: "GpxS3" [rails.rb#L67](https://github.com/openstreetmap/chef/blob/master/cookbooks/web/recipes/rails.rb#L67). It's the same standard the other services already use: avatars, traces and images are all set by name as service: "S3" today. I'll add the example config and a docs note, which are missing.

> Does it need to be in the rails owned ActiveStorage namespace, or could it be somewhere else?


>From what I saw in the default configs, Active Storage turns the config name into the class name. For example, S3 maps to S3Service, and if we set GpxS3 it maps to GpxS3Service. That's the default, so the name and the namespace have to match.

> What happens if somebody uses S3 and doesn't enable it? The traces still get compressed but don't get automatically decompressed on download?

This PR code gzips every plain GPX and stores it gzipped. The only difference between S3 and GpxS3 is the header: S3 stores the file without Content-Encoding, and GpxS3 adds it. So when a client asks for the file:

- With S3, the server decompresses it and sends back the plain GPX the user uploaded.
- With GpxS3, the app redirects to S3, which already has the Content-Encoding header. S3 sends the file and the browser decompresses it.

Either way the user gets their plain GPX back. Nothing breaks without GpxS3, we just decompress on the server instead of letting the browser do it.


> whether we need to automatically decompress them give we already have compressed traces and don't do that for them.

The goal in #4188 is to compress the plain GPX files that people upload, to save storage and transfer-out. The part I wanted to keep is that users get back what they uploaded. If a user uploads a .gpx, it downloads as .gpx today. If we store it as gz and serve it raw, that user gets a .gz instead, which changes the behavior. I don't think this differs from leaving user .gz uploads alone. The rule is the same: give back what was uploaded.

If we're ok with plain GPX downloading as .gz, this gets much simpler: compress on upload, no custom adapter, no Content-Encoding, no flag. It's more of a product call, and I'm happy to go that way if the decision is to download as .gz.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/7124#issuecomment-4770650961
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/7124/c4770650961 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260622/7d9314e7/attachment.htm>


More information about the rails-dev mailing list