[Patch draft] Specify Content-Encoding for HTTP connections

[simon04]

Currently, only the OsmServerReader specifies the HTTP request header Accept-Encoding: gzip, deflate to fetch the response in a compressed form (given the server supports it).

As a first improvement, Utils#openURLAndDecompress could also send this header and uncompress the returned InputStream:

src/org/openstreetmap/josm/tools/Utils.java

@@ -54 +54 @@
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 import java.util.zip.GZIPInputStream;
+import java.util.zip.Inflater;
+import java.util.zip.InflaterInputStream;
 import java.util.zip.ZipEntry;
 import java.util.zip.ZipFile;
 import java.util.zip.ZipInputStream;
@@ -800 +802 @@
      */
     public static InputStream openURLAndDecompress(final URL url, final boolean decompress) throws IOException {
         final URLConnection connection = setupURLConnection(url.openConnection());
+        connection.setRequestProperty("Accept-Encoding", "gzip, deflate");
         final InputStream in = connection.getInputStream();
         if (decompress) {
             switch (connection.getHeaderField("Content-Type")) {
@@ -811 +814 @@
                 return getBZip2InputStream(in);
             }
         }
+        switch (connection.getContentEncoding()) {
+        case "gzip":
+            return getGZipInputStream(in);
+        case "deflate":
+            return new InflaterInputStream(in, new Inflater(true));
+        }
         return in;
     }
 

In a next step, the 17 usages of Utils#openHttpConnection could be adapted one-by-one to also make use of HTTP compression.

[simon04]

Perhaps it also would make sense to use a more sophisticated HTTP client instead of keeping track of all those features ourselves. The one that came to my mind is ​https://github.com/google/google-http-java-client. Stripping it down to the "core packages" com.google.api.client.http, com.google.api.client.http.javanet and com.google.api.client.util, it should be about 200kb as JAR …

[simon04]

Close in favour of a broader solution in #12231.