[MGNLIMG-129] Images that don't exist cause a 500 instead of a 404 Created: 07/Apr/14  Updated: 14/Jun/18  Resolved: 11/Jun/18

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: 2.2.4, 3.0.3
Fix Version/s: 3.2.8, 3.3.2, 3.4.1

Type: Bug Priority: Neutral
Reporter: Rico Jansen Assignee: Michael Mühlebach
Resolution: Fixed Votes: 4
Labels: security, vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLIMG-190 Suppressing RuntimeException in Imagi... Closed
relation
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:
Epic Link: Support
Sprint: Basel 148, Basel 149
Story Points: 3

 Description   

When an image is requested on a path that does not exist, the code throws a PathNotFoundException in info.magnolia.module.templatingkit.imaging.generation.STKParameterProvider#83.

This gets not handled in info.magnolia.imaging.ImagingServlet#83 and results in a 500 error.

Better would be to handle this situation and return a 404 error.



 Comments   
Comment by Michiel Meeuwissen [ 15/Jan/16 ]

There is no activity on this issue for nearly 2 years. Can we agree that this is a bug?

Comment by Nils Breunese [ 19/Dec/16 ]

Example URL on Magnolia website: https://www.magnolia-cms.com/.imaging/stk/corporate2015_THISDOESNTEXIST/fullwidth/dam/rows-headers/homepage/homepage.jpg/jcr:content/homepage.jpg.jpg

This returns a 500 error with a stacktrace, instead of a 404 Not Found.

Comment by Michael Mühlebach [ 28/May/18 ]

We have quite a lot of logic linked to the URI path (like generators, sites, workspaces, etc) which is resolved before we actually look for the image. For those places (like creating jcr session for given repository) it might look like an actual error.
Atm we don't have specific exceptions or other means of better communication between the involved components. Therefore the most straightforward way is to turn the known exceptions (IllegalArgument & Runtime) into 404 which will probably turn some actual issues into 404. Imho this is the lesser of two evils because the exceptions are still logged.

But maybe there is a reason why turning some actual issues into 404 might be an even worse solution?!

Generated at Mon Feb 12 02:12:34 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.