[jira] Closed: (SLING-135) DefaultSlingServlet.spool is fragile w.r.t content-types

["Felix Meschberger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger closed SLING-135.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0
         Assignee: Bertrand Delacretaz

Closing this issue because it is fixed in microsling and Sling itself has a MIME type service.

The question of whether we might use the Tika Mime Type support is to be discussed on the list.

> DefaultSlingServlet.spool is fragile w.r.t content-types
> --------------------------------------------------------
>
>                 Key: SLING-135
>                 URL: https://issues.apache.org/jira/browse/SLING-135
>             Project: Sling
>          Issue Type: Bug
>          Components: microsling, MimeType
>            Reporter: Bertrand Delacretaz
>            Assignee: Bertrand Delacretaz
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> That method currently uses this code to set the content-type when spooling files:
>  protected void spool(URL url, SlingHttpServletResponse res) throws IOException {
>         URLConnection conn = url.openConnection();
>         // this previously used conn.getContentType(), but see SLING-112
>         res.setContentType(getServletContext().getMimeType(url.getFile()));
> Problem is, if microsling runs under a path that contains dots, like 
>   /usling.1.2/install, 
> url.getFile() returns the full path including dots, like 
>   /usling.1.2/install/foo/index.html
> and that failed on me when running with a somewhat exotic servlet engine, which probably broke the string after the first dot, didn't find a content-type and didn't accept getting null as a content-type.
> This should be made more robust.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.