servlet-spec
  1. servlet-spec
  2. SERVLET_SPEC-86

Support the specification of a content-encoding header for a resource based on file extension

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: HTTP
    • Labels:
      None

      Description

      This arose from this discussion on the Tomcat users mailing list:
      http://tomcat.markmail.org/thread/6x7izjf7ltphhh7r

      Compressed SVG files (*.svgz) require that the server sets the Content-Encoding header so that the user agent correctly renders the response.

      I would like to see the Servlet specification extended to allow applications to specify a Content-Encoding header for resources with a given file extension.

      Any setting of the Content-Encoding on the response would have to be mindful of any Accept-Encoding header sent by the user agent and the requirements of RFC 2616 section 14.3.

      This is very like the <mime-mapping> element currently used to configure Content-Type.

      I see two possible options:

      1. Add support for something along these lines
      <encoding-mapping>
      <extension>svgz</extension>
      <encoding>gzip</encoding>
      </encoding-mapping>

      2. Extend <mime-mapping> along these lines:
      <mime-mapping>
      <extension>svgz</extension>
      <mime-type>image/svg+xml</mime-type>
      <encoding>gzip</encoding>
      </mime-mapping>

      The second solution seems simpler but <mime-mapping> element would no longer be limited to MIME type mapping. The first solution is probably a better option.

        Activity

        Hide
        DaveLaw added a comment - - edited

        I believe "The second solution" is better:
        <mime-mapping>
        ____<extension>svgz</extension>
        ____<mime-type>image/svg+xml</mime-type>
        ____<encoding>gzip</encoding> <!-- optional -->
        </mime-mapping>
        :
        Unless there are overwhelming reasons to do so, it doesn't make sense
        to maintain two separate lists, both with the same "primary key" (<extension>),
        it would just make things (even) more confusing.
        Of course, the <encoding> attribute should be optional.
        And of course, it could perhaps be called, for example, <content-encoding>
        :
        I hope this can be resolved quickly, as I see the whole future of SVG Graphics
        threatened by the patchwork implementation we've seen to date, particularly as
        "plain-text" SVG's are so bloated, making compression very important.

        Show
        DaveLaw added a comment - - edited I believe "The second solution" is better: <mime-mapping> ____<extension>svgz</extension> ____<mime-type>image/svg+xml</mime-type> ____<encoding>gzip</encoding> <!-- optional --> </mime-mapping> : Unless there are overwhelming reasons to do so, it doesn't make sense to maintain two separate lists, both with the same "primary key" (<extension>), it would just make things (even) more confusing. Of course, the <encoding> attribute should be optional. And of course, it could perhaps be called, for example, <content-encoding> : I hope this can be resolved quickly, as I see the whole future of SVG Graphics threatened by the patchwork implementation we've seen to date, particularly as "plain-text" SVG's are so bloated, making compression very important.
        Hide
        Ed Burns added a comment -

        Would we need to add a corresponding annotation based configuration for this, or is XML alone sufficient?

        Show
        Ed Burns added a comment - Would we need to add a corresponding annotation based configuration for this, or is XML alone sufficient?
        Hide
        markt_asf added a comment -

        Re-referencing markmail - the IDs seem to have changed:
        http://markmail.org/thread/oatgj63lrgc4kvh6

        I'd be happy with an option encoding element adding to mime-mapping.

        Currently, mime-mappings are only configurable via XML (unless I missed something) so I think that would be sufficient for this new element as well.

        Show
        markt_asf added a comment - Re-referencing markmail - the IDs seem to have changed: http://markmail.org/thread/oatgj63lrgc4kvh6 I'd be happy with an option encoding element adding to mime-mapping. Currently, mime-mappings are only configurable via XML (unless I missed something) so I think that would be sufficient for this new element as well.

          People

          • Assignee:
            Unassigned
            Reporter:
            markt_asf
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: