Jetty
  1. Jetty
  2. JETTY-271

prefer content type of resource over path info

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.1.2rc2
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      1

      Description

      ResourceHandler currently uses the request's path(info) to determine the mime type for a response. The attached patch first tries the file of the actual resource, and when that is null, falls back to the path.

      This solves at least one particular issue. I have a site with index.html that uses http-equiv=Refresh to redirect to the servlet part of the site. The problem is that in that case the mime type is not set as though the welcome file is successfully resolved to index.html, pathinfo is empty as the request came in on /. And because the mime type is not set, Safari thinks it should just download the file (not on the first hit, as the resource isn't cached yet then, but on the next ones).

      The patch fixes this. I'm not sure if this is the best way to fix it, as it is slightly more expensive to get the file and the file name (URL probably would work as well I guess). The most efficient way to solve this is probably to use the path from the resource only when the request is to the welcome file. But I'll leave that up to you guys to decide what the best one is.

        Activity

        Hide
        Greg Wilkins added a comment -

        I have done a fix that is inspired by yours.

        I try the Resource.toString and if that fails to find a mime type I use the pathInfo

        Show
        Greg Wilkins added a comment - I have done a fix that is inspired by yours. I try the Resource.toString and if that fails to find a mime type I use the pathInfo
        Hide
        Eelco Hillenius added a comment -

        Thanks. Say, wouldn't it be better to use getUrl().toString() (maybe with a null check if that's needed)? Using toString seems kind of fragile to me? Just my 2c.

        Show
        Eelco Hillenius added a comment - Thanks. Say, wouldn't it be better to use getUrl().toString() (maybe with a null check if that's needed)? Using toString seems kind of fragile to me? Just my 2c.
        Hide
        Greg Wilkins added a comment -

        Eelco,

        the Resource implementations all give their as their string representation their canonical form,
        which for URL resources is their URL. For non URL resources, it may be their file name, but
        regardless, all schemes that I know of will have the suffix ending.

        Show
        Greg Wilkins added a comment - Eelco, the Resource implementations all give their as their string representation their canonical form, which for URL resources is their URL. For non URL resources, it may be their file name, but regardless, all schemes that I know of will have the suffix ending.
        Hide
        Eelco Hillenius added a comment -

        Hi Greg,

        Yup I saw the implementations. I just believe that it is generally better practice not to use toString for anything else than debugging etc. Not a biggy though

        Show
        Eelco Hillenius added a comment - Hi Greg, Yup I saw the implementations. I just believe that it is generally better practice not to use toString for anything else than debugging etc. Not a biggy though

          People

          • Assignee:
            Greg Wilkins
            Reporter:
            Eelco Hillenius
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: