#2190 closed enhancement (not a bug)

Enable optional gzip compression on HTTP server tunnel

Reported by: Reportage Owned by:
Priority: minor Milestone: undecided
Component: apps/i2ptunnel Version: 0.9.34
Keywords: gzip, i2ptunnel, http server Cc:
Parent Tickets:

Description

Rather than enabling compression in jetty for the default eepsite, adding the option to gzip at the HTTP server level would provide more flexibility, allowing transparent compression of 3rd party web servers without the need to install additional modules (if available). A checkbox in the UI to enable (under Server Access Options?) would simplify usage.

Subtickets

Change History (6)

comment:1 Changed 14 months ago by Reportage

  • Type changed from defect to enhancement

comment:2 Changed 14 months ago by zzz

  • Resolution set to invalid
  • Status changed from new to closed

All client/server traffic through I2P is transparently gzipped at the I2CP layer. In addition, the HTTP client and server proxies transparently gzip at that layer, with some logic so it doesn't bother if the web server gzipped it already. Neither may be disabled by user configuration, I don't think.

Gzipping by the web server has some modest advantages, in that 1) if the server isn't jetty, it's out of the I2P java server process; and 2) the browser does the decompression, so it's out of the I2P java client process. On the downside, Jetty discourages on-the-fly gzipping of static content, as it's relatively inefficient for them, since they can't use NIO. The preferred way is for the user to gzip the static files. That's why we added some configuration for Jetty to do that, relatively recently.

In summary, I think we already do what you're asking for. Twice. If I'm wrong, please reopen with more info.

comment:3 Changed 13 months ago by Reportage

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 0.9.33 to 0.9.34

Browsing a locally hosted .i2p domain that's being served by a 3rd party web server, I'm not seeing compression on files that are not being explicitly gzipped by the server. Looking at the traffic in Firefox's net monitor, there are no "content-encoding" response headers being sent.

Perhaps the hybrid nature of the server, which compresses dynamically generated content but not static content, is confusing the tunnel logic?

Update: With python's basic webserver python -m SimpleHTTPServer 80 that provides no native compression, the http server tunnel does not compress content when accessed via the the .i2p address. Furthermore, proxy error messages are being missed which suggests that the tunnel isn't implementing compression correctly (or at all?).

Last edited 13 months ago by Reportage (previous) (diff)

comment:4 Changed 13 months ago by zzz

  • Status changed from reopened to infoneeded

Not sure you're looking in the right places for the evidence.

1) On the server side, just look if the request header contains Accept-Encoding: gzip. If that's passed through we did our job. Whether the server actually compresses is up to him and depends on mime type, content length, and configuration. Most servers don't compress static content by default.

2) For the transparent gzipping between server and client tunnels, it's transparent externally (i.e. it's uncompressed by the client proxy) and won't be visible to the browser. You'd have to enable logging of the classes that handle that. And the server tunnel is also selectively compressing based on mime type and content length.

comment:5 Changed 13 months ago by slumlord

  • Status changed from infoneeded to open

I have a few I2P-connected web servers running, with gzip & static-gzip enabled (nginx). I am able to see Content-Encoding: gzip header as well as the difference in Transferred vs. Actual size in the developer console of my web browser.

comment:6 Changed 12 months ago by zzz

  • Resolution set to not a bug
  • Status changed from open to closed

In discussion on IRC a few weeks ago, I explained comment 4 further. I also opened up #2221 - which is how OP thought it did (should?) work now - as a possible enhancement. This ticket is not-a-bug.

Note: See TracTickets for help on using tickets.