Opened 18 months ago

Last modified 10 days ago

#2102 assigned enhancement

UX enhancements to jetty eepsite server

Reported by: Reportage Owned by: sadie
Priority: minor Milestone: undecided
Component: apps/jetty Version: 0.9.32
Keywords: jetty eepsite UX Cc:
Parent Tickets:

Description

The default personal webserver is an asset to the I2P suite, but could be
enhanced to make it more attractive to new users. Digging through various xml
files to configure the server is user hostile. A configuration UI to control
various aspects of jetty would be welcome by many, no doubt. Possible options
might include:

Subtickets (add)

Change History (10)

comment:1 Changed 18 months ago by zzz

  • Component changed from unspecified to apps/jetty
  • Status changed from new to open

Agreed, Jetty configuration is miserable because it's XML. Additionally, their website docs aren't great. And they tend to hide the docs for the version we're using, because shortly after we migrate to some version they've declared it EOL. For example, we're on 9.2.x and the link above is for 9.4.7.

It would be very difficult to put a nice skin on top of Jetty config. For most people that want to customize things, we recommend using something simpler and more familiar, such as apache, nginx, or lighttpd. The one thing they can't do is handle .war files. In theory, you can just throw webapps in the eepsite/webapps dir, but nobody ever asks about it.

We could add some limited stuff in the console that looks over at jetty. Right now we have nothing. The router/client separation means the router and the console, in theory, don't even know there's a 2nd jetty instance for the eepsite running in the JVM at all, except as a generic client (see /configclients). So nothing would be straightforward.

A new or better help page may be a good place to start.

comment:2 Changed 17 months ago by Reportage

In theory, you can just throw webapps in the eepsite/webapps dir, but nobody ever asks about it.

I'm seeing a 404 when attempting to access .war files in http://127.0.0.1:7658/webapps, and the same 404 when attempting to access the containing directory http://127.0.0.1:7658/webapps/ which suggests that the directory isn't being correctly mapped.

comment:3 Changed 17 months ago by zzz

No, that's not the way it works.

The webapps dir can be configured in jetty.xml to be scanned periodically, although I don't think it does so by default. If it's not, it will definitely load it on startup.

A webapp foo.war in the webapps/ dir will generally be accessible at http://127.0.0.1:7658/foo/ unless configured otherwise.

comment:4 Changed 17 months ago by Reportage

OK, thanks. It's now working with a test app: https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/
accessible via http://127.0.0.1:7658/sample/

To better promote this feature, a couple of ideas:

  • Better documentation needed to explain how to deploy webapps: an additional paragraph in the eepsite help html file, and a text file in the webapps directory.
  • A demo/simple I2P-specific .war to demonstrate the feature, linked from the eepsite help page.
  • Enable automatic scanning of the webapps dir every 120 seconds to remove the need to reboot the router to deploy .war files.

comment:5 Changed 16 months ago by Reportage

Some low-hanging fruit:

  • Custom error messages: Ideally a visitor to a Jetty-run eepsite should never be able to determine that the site is running Jetty from server headers or other clues. Custom(izable) error messages go some way to achieving this goal, especially if the user is encouraged to customize. http://www.eclipse.org/jetty/documentation/current/custom-error-pages.html
  • Custom directory listings by default: As above, the default format advertises a Jetty server to anyone that has any experience with Jetty, in addition to being ugly. Seems the heavy listing has already been done here: http://127.0.0.1:7658/help/lib/ so, again, using this as the default for directory listings and encouraging the user to customize would help reduce Jetty's advertised profile. https://www.eclipse.org/jetty/documentation/9.4.x/resource-handler.html (9.4 but broadly the same as 9.2?)
  • Console link/page for Jetty's access logs
  • Add HTTP server tunnel option to allow spoofing of server identity (or complete removal of header)
Last edited 16 months ago by Reportage (previous) (diff)

comment:7 Changed 15 months ago by zzz

Thanks, but we certainly know how to deal with XML in Java, we do it already, both in UPnP and the news feed. Additionally, we have access to the Jetty XML configuration classes. Lack of examples is not the issue. It's still miserable.

Some of this may get solved as a part of #2159, where I'm contemplating a "wizard" or other mechanism to set up HTTPS for eepsites. To accomplish that we need to inspect and rewrite the configuration in jetty-ssl.xml.

Re: comment 4 last bullet, you don't have to restart the router if you change something with the eepsite, you just have to stop and restart jetty on /configclients.

Re: OP first bullet and comment 5 first bullet, agreed, would be nice to get rid of the 'powered by Jetty' on the 404 page. I'm not sure that removing any fingerprints of Jetty is feasible, there's so many things servers do in the headers that make it easy. But we could investigate.

Re: comment 5 2nd bullet, I just checked in a change to disable directory listings by default (new installs only). Even if we changed the CSS, it still wouldn't look like Apache or nginx or anything else. Not sure what the point of only "reducing the advertised profile". We'd have to output exactly the same HTML and CSS as some other server.

Re: comment 5 last bullet, the Server and X-Powered-By headers are already stripped in the HTTP server tunnel.

comment:8 Changed 15 months ago by Reportage

The option to display or suppress directory listings is exactly the type of configuration setting that would benefit from a UI. One xml file to configure the server would be challenging enough, but looking at the eepsite structure, we have:

  • jetty.xml
  • jetty-jmx.xml
  • jetty-rewrite.xml
  • jetty-ssl.xml
  • base-context.xml
  • cgi-context.xml
  • web-default.xml

Consolidating these with a single page that allows basic configuration would go a long way to addressing the headache that is currently jetty configuration. At its most basic, parsing all the configurable values and presenting in similar vein to the console's advanced configuration page, with accompanying help text, would be a start. Ideally, a full-blown UI with checkboxes etc would provide the most value.

Regarding 404's and custom directory listings, the proposal encompasses 2 goals: firstly, presentation. Custom 404s and directory listings enhance the user experience and give the impression that due care and attention has gone into differentiating I2P services from generic installations. Allowing the user simple configuration options for customization by providing templates for the error messages and directory listings (outside of the web server root directory) puts the user in control. Masking the server identity is secondary, and spoofing the output of other servers probably isn't worth the effort, though the option to edit the html in addition to the css would allow for more obscurity.

comment:9 Changed 5 weeks ago by zzz

  • Owner set to sadie
  • Status changed from open to assigned

assigning to sadie for evaluation and prioritization based on user feedback and use cases

comment:10 Changed 10 days ago by zzz

Jetty enhanced their directory listings to add support for sorting columns, in 9.2.28 and 9.4.18 (actually in the releases before that, but there were bugs). drz proposed in IRC to leverage that code in our I2PDefaultServlet. That's possible, but low-priority. It also can't happen unless/until Debian/Ubuntu? update to those releases, as the burden of supporting pre- and post-changes would be too high.

Note: See TracTickets for help on using tickets.