context relative css image path references not handled

I'm not sure what this has to do with jetty?
Jetty does not generate the content and the resulting
URL is really a 404?

How do you see jetty helping with this?

Well, jetty isn't generating the content but it is managing it. Meaning that these are just static context relative
resources and paths that get served up by whatever servlet container happens to be hosting them.

I'm not entirely certain I'm right but this section :

http://www.w3.org/TR/CSS21/syndata.html#uri

Suggests that the base URI would be the "stylesheet" (ie http://domain/context/Foo.css) and any resources being resolved relative to it would use that path as the base.

The content is there if it uses the incoming URI to handle it.

Jesse, can capture the URI that the browser is generating with LiveHttpHeaders or wireshark or something else?

Yeah sure. Though I should say that I partially did that by using the firefox web deb plugin "show broken images" feature to track down what it was requesting. (the image path originally quoted in the first comment, http://localhost:8080/js/dojo/src/widget/templates/DatePicker.cssimages/dpBg.gif )

I can try again with firebug or something else more robust. (never heard of wireshark, maybe that's another ff extension ? )

If needed I can probably produce a war to re-produce this from the original app I was testing it in, http://opencomponentry.com:8080/timetracker . (the url referenced is working fine, but the dojo js assets are being managed in tapestry from the default bundled dojo in the demo)

Jesse, if you're using firefox, you should find LiveHttpHeaders a dream to use. It shows you the whole http dialog between browser and server. Instrall it from here: http://livehttpheaders.mozdev.org/installation.html.

You will be able to capture it as a log file too. I'm interested in seeing the url of the request the browser issues to get your css file.

BTW, wireshark (used to be called Ethereal) is here: http://www.wireshark.org/. It's a network packet sniffer, and can also show you the HTTP conversation (as well as every IP packet).

Http input/output from single request.

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.

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.

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

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...