[MAGNOLIA-6477] Move setting of Content-Type out of the ContentTypeFilter to where the content is actually generated. Created: 31/Dec/15  Updated: 25/Feb/16  Resolved: 08/Jan/16

Status: Closed
Project: Magnolia
Component/s: rendering
Affects Version/s: None
Fix Version/s: 5.3.13, 5.4.5

Type: Epic Priority: Neutral
Reporter: Robert Šiška Assignee: Robert Šiška
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLRES-251 Deprecate contentType field in Resour... Closed
Template:
Epic Name: Move setting of Content-Type header to where the content is generated
Acceptance criteria:
Empty
Sprint: Kromeriz 24

 Description   

Magnolia sets Content-Type header right in the ContentTypeFilter (which is #2 filter in default config).
It finds out the MIME-type based on the extension using the MIMEMapping. This caused clients some problems (see MAGNOLIA-6367).

IMHO the correct approach is to set the Content-Type header where the content is actually generated - so mostly in renderers.
ResourceTemplate already allows setting up contentType, so I propose to move it up to RenderableDefinition API so that all renderers can react to it.

Problems this change would cause:
The ResponseContentTypeVoter relies on Content-Type being set. Solution to this would be re-purpose this listener to examine request extension instead, since that is what it does anyway.
Another trivial problem is wrong MIME-type of JCR-exports (application/octet-stream instead of correct application/xml.


Generated at Mon Feb 12 04:14:54 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.