After upgrading a MangoES installation to core 2.8.8 with mangoESConfiguration 1.2.2, opening /system_settings.shtm can fail with ERR_CONTENT_DECODING_FAILED. The server evidence shows an HTTP 500 response and a Jetty compression error, so treat the browser message as the visible result of a server-side rendering failure rather than proof that the page moved.
Identify the failure signature
| Evidence | Engineering interpretation |
|---|---|
| Core 2.8.8 | The fault appeared after this core upgrade. |
| mangoESConfiguration 1.2.2 | This was the installed configuration-module version. |
/system_settings.shtm |
This is the failing application route. |
ERR_CONTENT_DECODING_FAILED |
The browser could not decode the returned content. |
javax.servlet.error.status_code=500 |
The application generated a server error while handling the request. |
java.lang.IllegalStateException: Committed |
The response had already been committed when the compression wrapper attempted to reset its buffer. |
Separate the browser symptom from the server fault
The initial stack passes through GzipFilter, CompressedResponseWrapper.resetBuffer, the shallow ETag filter, Spring Security filters, and the application error page. This confirms that compression participates in the failed response path, but it does not prove that compression is the primary defect. The HTTP 500 and forwarded route to /exception/error.jsp show that server-side processing failed before the browser reported its decoding error.
Clearing the browser cache is a supported diagnostic action because stale cached content can affect browser behavior. However, a cache clear does not address the recorded server exception; use the server log to decide whether the failure remains application-side.
Collect the complete diagnostic record
Inspect Mango/logs/ma.log for entries surrounding the failed request. Preserve the first exception and any nested Caused by section; the browser message alone cannot distinguish a malformed compressed response from a JSP compilation or loading problem.
Before sharing logs, remove session cookies, CSRF tokens, password hashes, email addresses, and other account or authentication data. Those fields are not required to diagnose the JSP and response-processing failure.
Check the upgrade environment
- Confirm that the filesystem containing Mango has free space. A full disk is a supported hypothesis for failure to create or compile JSP work files.
- Check for module updates compatible with the installed 2.8 core line. The evidence states that the modules were already reported as current, so record that result rather than repeatedly applying the same check.
- Verify that
web.jsp.development=trueexists inenv.properties. This was specifically recommended for the JSP troubleshooting path. - Determine whether any JSP files were overridden. The reported installation stated that no files had been overridden, which reduces the likelihood of a custom JSP causing this case.
- Clear the browser cache, retry
/system_settings.shtm, and correlate the retry with the new entries inMango/logs/ma.log.
Rebuild the JSP work output
Delete the Mango/work/jsp directory and reload the page. This action targets generated JSP work products rather than application source files. In the reported case, it did not restore System Settings; instead, the next request exposed a more specific JSP class-loading failure.
Do not record deletion of the JSP work directory as a confirmed fix for this incident. Its diagnostic value was that it changed the visible exception from the response-commit path to org.apache.jasper.JasperException caused by a missing generated JSP class.
Interpret the post-cleanup exception
After the JSP work directory was removed, the server reported java.lang.ClassNotFoundException: org.apache.jsp.index_jsp. The stack shows Jasper attempting to load the generated class through JasperLoader and failing while serving the JSP.
This narrows the fault boundary: the regenerated index_jsp class was not available when requested. The evidence does not establish whether compilation failed, generated output could not be written, or the class was otherwise unavailable. Use disk-space status, the web.jsp.development setting, and the earlier log lines around the Jasper exception to discriminate among those possibilities.
Use the exception transition as the decision path
| Observed result | Next decision |
|---|---|
| The retry succeeds after clearing browser cache | Confirm repeated access and treat stale client content as the supported cause. |
IllegalStateException: Committed remains |
Capture the first server exception preceding the compression-wrapper failure; do not diagnose from the browser code alone. |
ClassNotFoundException: org.apache.jsp.index_jsp appears after removing Mango/work/jsp
|
Investigate JSP regeneration: free space, the development setting, and earlier Jasper compilation messages. |
| JSP overrides are present | Compare the overridden files with the upgraded installation before continuing. |
| No overrides and modules are current | Retain those exclusions and focus on JSP generation evidence in ma.log. |
Verify recovery
Recovery is verified only when /system_settings.shtm loads repeatedly and a correlated log review shows no new HTTP 500, IllegalStateException: Committed, JasperException, or ClassNotFoundException: org.apache.jsp.index_jsp. Confirm that the page is usable after a fresh request, not merely displayed from browser cache.
FAQ
Why does MangoES 2.8.8 show ERR_CONTENT_DECODING_FAILED?
The recorded request generated HTTP 500 while Jetty's compression wrapper handled an already committed response. Inspect Mango/logs/ma.log for the earlier server exception because the browser code identifies the response symptom, not the primary cause.
Should I delete Mango/work/jsp to fix System Settings?
Deleting Mango/work/jsp forces the generated JSP work output to be rebuilt, but it was not a confirmed fix in this case. The retry instead produced ClassNotFoundException: org.apache.jsp.index_jsp, which directs troubleshooting toward JSP regeneration.
What should web.jsp.development be for this JSP fault?
Verify web.jsp.development=true in env.properties. Then reload /system_settings.shtm and inspect the correlated ma.log entries for JSP compilation or class-loading errors.