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

[Pablo Brasero]

@pablobm commented on this pull request.

I think it's worth creating a PR for Rails to support `content_encoding` here. I had a quick look and there doesn't seem to be any issue or PR.

That might not go anywhere, or perhaps it does. In any case it could give us some additional insight, if there's some detail we are overlooking. It doesn't need to block this PR: if in the future it's merged, we can drop the custom service.

> @@ -0,0 +1,43 @@
+# frozen_string_literal: true
+
+module GpxDownloadMethods
+  extend ActiveSupport::Concern
+
+  private
+
+  # Send the stored trace file to the client. It can go back two ways.
+  # - If the store serves gzip (S3) and the client accepts it, redirect and let the client unzip it.
+  # - Otherwise the server unzips it first and sends plain GPX.
+  def send_trace_file(trace)
+    if gzipped_by_server?(trace)

Right. So now I see it's not dead in the case where `request_accepts_gzip?` is false. However: is there any use to checking `store_serves_gzip?(trace)`?

My thinking is: if `gzipped_by_server?(trace)` is true, then surely `store_serves_gzip?(trace)` is also true. I'm trying to think a case where this hypothesis might break, perhaps by changing services and so mixing files that have and have not been gzipped, etc, and I can't quite picture it. Do you have an example?

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

Message ID: <openstreetmap/openstreetmap-website/pull/7124/review/4617173119 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260702/12f03097/attachment.htm>