[MGNLIMG-240] error page 500 Created: 15/Apr/21 Updated: 18/Oct/22 Resolved: 17/Mar/22 |
|
| Status: | Closed |
| Project: | Imaging |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.3 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Tomáš Gregovský | Assignee: | Jesus Alonso |
| Resolution: | Fixed | Votes: | 6 |
| Labels: | VN-Testing | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 50m | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[X]*
Doc/release notes changes? Comment present?
[X]*
Downstream builds green?
[X]*
Solution information and context easily available?
[X]*
Tests
[X]*
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: | |
| Epic Link: | AuthorX Maintenance |
| Sprint: | AuthorX 5 |
| Story Points: | 1 |
| Description |
|
Originally reported one of our client, we provided fix but I believe this should be handled ootb by Magnolia:
Story: Checking logs of live projects, we are maintaining in-house, all of them contains ERRORs 500. Most of them due to wrong links to imaging. There is recognised pattern which has cut original link and adds there dots ... at the end of it. for example: we are sure these are not generated by our templates but are more probably caused some external indexing robots, pages with links, etc.... and so we can't fix these links. Anyway in this case of accessing mentioned link above, magnolia throws status 500 error with ugly stack trace.
Possible fix: similarly like 404 page, this piece of code should be added to web.xml: <error-page> <error-code>500</error-code> <location>/docroot/500.html</location> </error-page> plus some simple template in docroot itself.
Would be nice if Magnolia has this error handling already build in. Thank you.
|
| Comments |
| Comment by Michael Duerig [ 02/Mar/22 ] |
|
While I think it is a good idea to add error pages to `web.xml`, in this specific case we should also fix imaging. Accessing an non existing URL should not cause a 500 but a http status from the 400 range. E.g. a 404. |
| Comment by Jesus Alonso [ 16/Mar/22 ] |
|
ImagingServlet is prepared for responding with a 404. The problem is simply that is expecting an ImagingException, but is receiving instead an UncheckedExecutionException which contains the ImagingException |