Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-6477

Move setting of Content-Type out of the ContentTypeFilter to where the content is actually generated.

    XMLWordPrintable

Details

    • Epic
    • Resolution: Fixed
    • Neutral
    • 5.3.13, 5.4.5
    • None
    • rendering
    • None
    • Move setting of Content-Type header to where the content is generated
    • 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.

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                rsiska Robert Šiška
                rsiska Robert Šiška
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: