Opened 12 months ago

Closed 11 months ago

Last modified 11 months ago

#2157 closed enhancement (fixed)

Enable gzip compression for console and webapps when client != 127.0.0.1

Reported by: Reportage Owned by:
Priority: maintenance Milestone: 0.9.34
Component: apps/console Version: 0.9.33
Keywords: console, gzip Cc:
Parent Tickets:

Description

In order to make accessing the console over the network more responsive, enabling gzip compression should be considered. If the console (or anything served via the default jetty) is accessed on localhost, gzip isn't needed. If the console is accessed via any other address, gzip could be enabled for clients that support it. This could either be automatic, or via a preference / UI option. Conditional compression for standalone snark might also be worth enabling.

Subtickets

Change History (8)

comment:1 Changed 12 months ago by Reportage

  • Summary changed from Enable gzip compression for console and webapps when host != 127.0.0.1 to Enable gzip compression for console and webapps when client != 127.0.0.1

comment:2 Changed 12 months ago by zzz

  • Component changed from unspecified to apps/console
  • Priority changed from minor to maintenance
  • Status changed from new to open

Not a common use case, very few people do remote console.
Not sure if it would be easy or even possible to do it only if not local.
If it's all or none, probably not worth the increased CPU for local compression.
Low priority unless somebody really needs it.

comment:3 Changed 11 months ago by Reportage

CPU usage should be fairly light if compression is limited to html/css/js/svg. Initially, a preference/UI option to enable gzip on the console and webapps would allow a better assessment of usefulness/performance. Remote access of webapps would also benefit, not least I2PSnark. Potential for +-80% shrinkage on some of the content.

comment:4 Changed 11 months ago by zzz

Right, to assess the usefulness/performance and decide whether to implement it, we have to implement it.

comment:5 Changed 11 months ago by Reportage

Not much to do on the implementation front, as gzip compression is already enabled for the http server tunnel, so more a question of cut and paste.

comment:6 Changed 11 months ago by zzz

Incorrect. The HTTP server tunnel has nothing to do with the console.

comment:7 Changed 11 months ago by zzz

  • Milestone changed from undecided to 0.9.34
  • Resolution set to fixed
  • Status changed from open to closed

One other justification - pure speculation - that with HTTPS console (#2160), compression before encryption may be cheaper than encryption of something far larger.

In 019010cf4eb46dff5e7f2761aaf2fb30eb21abcd 0.9.33-14, configured as follows:

  • enabled by default, disable with adv. config routerconsole.enableCompression=false
  • 64KB minimum size to compress, unless chunked, but almost all HTML output is chunked
  • only for mime types text/plain, text/html, text/css, and similar
  • not dependent on source IP

I didn't look at the source IP, because one of the most beneficial use cases would be ssh tunneling, where it would be localhost anyway

comment:8 Changed 11 months ago by zzz

On further testing, the logic described above was not implemented correctly.
Fixed in 3ce719d6d83e0f6781efe1194f5badf63f23d167 to be 0.9.33-15

Note: See TracTickets for help on using tickets.