Jetty
  1. Jetty
  2. JETTY-178

context relative css image path references not handled

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 6.1.0
    • Fix Version/s: None
    • Component/s: Servlet
    • Labels:
      None
    • Environment:
      maven2 using 6.1-SNAPSHOT jetty plugin
    • Number of attachments :
      2

      Description

      I have a web application experiencing some broken links when context relative image paths are referenced in embedded css file references.

      The directory layout consists of one static "/js/" context directory containing a dojo build. Everything works for the most part besides one tiny portion. Specifically when including a css file with a path of:

      http://localhost:8080/js/dojo/src/widget/templates/DatePicker.css

      I get my css file served up just fine, but the following type of block contained in said css file is where things get messed up:

      .calendarBodyContainer {
      width:100%; /* needed for the explode effect (explain?) */
      background: #7591bc url("images/dpBg.gif") top left repeat-x;
      }

      The above "images/dpBg.gif" url reference will be interpreted by the browser and cause a request going out looking exactly like:

      http://localhost:8080/js/dojo/src/widget/templates/DatePicker.cssimages/dpBg.gif

      This currently returns a 404 not found error. I ran into a similar issue while working on bundling dojo with Tapestry and had to handle relative image css paths. My perhaps questionable solution was in the "translateCssPath" method found in this source file:

      http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/asset/AssetService.java?view=markup

      1. httpheadercapture.txt
        59 kB
        Jesse Kuhnert
      2. ie7_fiddler_io.txt
        606 kB
        Jesse Kuhnert

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Http input/output from single request.

        Show
        Jesse Kuhnert added a comment - Http input/output from single request.
        Hide
        Jan Bartel added a comment -

        Jesse,

        This exchange shows the browser requesting the wrong url:

        http://localhost:8080/js/dojo/src/widget/templates/DatePicker.cssimages/dpHorizLine.gif

        GET /js/dojo/src/widget/templates/DatePicker.cssimages/dpHorizLine.gif HTTP/1.1
        Host: localhost:8080
        User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
        Accept: image/png,/;q=0.5
        Accept-Language: en-us,en;q=0.5
        Accept-Encoding: gzip,deflate
        Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
        Keep-Alive: 300
        Connection: keep-alive
        Referer: http://localhost:8080/app

        HTTP/1.x 404 Not Found
        Content-Type: text/html; charset=ISO-8859-1
        Content-Length: 1442
        Connection: keep-alive
        Server: Jetty(6.1-SNAPSHOT)

        Jetty does not interpret the contents of the css file at all. That's the brower's job. If you look on the Firefox bug list at http://www.mozilla.org/support/firefox/bugs there are quite a few concerning css. I'd try a) upgrading firefox and/or b) a different browser and see what happens.

        Show
        Jan Bartel added a comment - Jesse, This exchange shows the browser requesting the wrong url: http://localhost:8080/js/dojo/src/widget/templates/DatePicker.cssimages/dpHorizLine.gif GET /js/dojo/src/widget/templates/DatePicker.cssimages/dpHorizLine.gif HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy) Accept: image/png, / ;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:8080/app HTTP/1.x 404 Not Found Content-Type: text/html; charset=ISO-8859-1 Content-Length: 1442 Connection: keep-alive Server: Jetty(6.1-SNAPSHOT) Jetty does not interpret the contents of the css file at all. That's the brower's job. If you look on the Firefox bug list at http://www.mozilla.org/support/firefox/bugs there are quite a few concerning css. I'd try a) upgrading firefox and/or b) a different browser and see what happens.
        Hide
        Jesse Kuhnert added a comment -

        What luck I must have! It seems I'm the first one to find a bug that exhibits the same behavior across all known browsers. I tested this in konqueror (ie khtml which is close enough to safari ) / opera / ie7 and they all requested the same image path with the same broken results.

        I've attached a new header request/response session captured using fiddler and ie7 for comparison.

        Show
        Jesse Kuhnert added a comment - What luck I must have! It seems I'm the first one to find a bug that exhibits the same behavior across all known browsers. I tested this in konqueror (ie khtml which is close enough to safari ) / opera / ie7 and they all requested the same image path with the same broken results. I've attached a new header request/response session captured using fiddler and ie7 for comparison.
        Hide
        Greg Wilkins added a comment -

        Jesse,

        your sarcasm aside.... I simply do not see how this can be a jetty bug.

        We do not manipulate content in anyway!

        It is the browser that has added /js/dojo/src/widget/templates/TimePicker.css to images/dpCurveTL.png
        and obtained /js/dojo/src/widget/templates/TimePicker.cssimages/dpCurveTL.png

        I don't see how jetty can affect this at all?
        We can't change the content of the css
        We can't server a URL like the above because it is wrong
        We can't effect how the browser is resolving this relative path.

        Normally this sort of thing can be caused by a URL like
        TimePicker.css/ but I don't see this in your request? So I am as puzzled as you why the relative URLs are not being correctly
        interpreted. But I again say that it is not a Jetty issue as we are not involved in the resolution of the relative path.

        sorry

        Show
        Greg Wilkins added a comment - Jesse, your sarcasm aside.... I simply do not see how this can be a jetty bug. We do not manipulate content in anyway! It is the browser that has added /js/dojo/src/widget/templates/TimePicker.css to images/dpCurveTL.png and obtained /js/dojo/src/widget/templates/TimePicker.cssimages/dpCurveTL.png I don't see how jetty can affect this at all? We can't change the content of the css We can't server a URL like the above because it is wrong We can't effect how the browser is resolving this relative path. Normally this sort of thing can be caused by a URL like TimePicker.css/ but I don't see this in your request? So I am as puzzled as you why the relative URLs are not being correctly interpreted. But I again say that it is not a Jetty issue as we are not involved in the resolution of the relative path. sorry
        Hide
        Jesse Kuhnert added a comment -

        I finally found my error last week. Sorry for trying to pin this one on jetty. Temporary insanity or stupidity didn't allow for the possibility that it could possibly be my problem for a while...shrug...

        Show
        Jesse Kuhnert added a comment - I finally found my error last week. Sorry for trying to pin this one on jetty. Temporary insanity or stupidity didn't allow for the possibility that it could possibly be my problem for a while...shrug...

          People

          • Assignee:
            Unassigned
            Reporter:
            Jesse Kuhnert
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: