#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: Sensitive: no

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 19 months ago by Reportage

Type: defectenhancement

comment:2 Changed 19 months ago by zzz

Resolution: invalid
Status: newclosed

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 18 months ago by Reportage

Resolution: invalid
Status: closedreopened
Version: 0.9.330.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 18 months ago by Reportage (previous) (diff)

comment:4 Changed 18 months ago by zzz

Status: reopenedinfoneeded

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 18 months ago by slumlord

Status: infoneededopen

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 17 months ago by zzz

Resolution: not a bug
Status: openclosed

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.