[MAGNOLIA-2936] Error pages not served properly Created: 10/Nov/09 Updated: 23/Jan/13 Resolved: 15/Dec/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: if (statusCode != HttpServletResponse.SC_OK) { return; } This links back to
Given the current code of GZipFilter, if there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) |
| Comments |
| Comment by Jan Haderka [ 11/Nov/09 ] |
|
AFAIK the problem here is with the errors that come not from magnolia but from the underlying server infrastructure. In case of Magnolia related errors, the response is not committed even after setting the error header, but if it is the Tomcat who gets the error, it will commit the original response because it keeps reference to it and doesn't access the wrapped response that GZipFilter swapped for the original. |
| Comment by Magnolia International [ 11/Nov/09 ] |
|
The piece of code mentioned above is also necessary for redirects |
| Comment by Magnolia International [ 13/Nov/09 ] |
|
One of the inline comments says: Another thing that might be related or not: the CacheResponseWrapper does not implement containsHeader and probably should. I haven't committed this, since I'm not sure how it should do this: public boolean containsHeader(String name) { return super.containsHeader(name) || headers.containsKey(name); // or return headers.containsKey(name); } (probably the former, since headers might have been prior to this wrapper) |
| Comment by Magnolia International [ 13/Nov/09 ] |
|
Also see |
| Comment by Jan Haderka [ 16/Nov/09 ] |
The call to sendError() method causes response to be committed (check the spec). |