Bug 13355 – Images on lilypond.org do not load because they expect an Accept: header with image/png

• Status: NEW
• Component: Page Loading

[Moshe Dror]

When loading the URL, there are images on the page. They do not load with Webkit.
They do load with Firefox.
That goes for this URL too:

http://lilypond.org/doc/v2.10/input/test/collated-files

The server is picky:

$ curl -I -H "Accept: */*" "http://lilypond.org/doc/v2.10/input/test/lily-0c257c31dd"
HTTP/1.1 200 OK
Date: Sun, 15 Apr 2007 20:50:27 GMT
Server: Apache
Content-Location: lily-0c257c31dd.txt
Vary: negotiate,accept,accept-charset,Accept-Encoding
TCN: choice
Set-Cookie: id=89.0.180.58.dynamic.barak-online.net.291851176670227631; path=/
Set-Cookie: id=89.0.180.58.dynamic.barak-online.net.291851176670227631; path=/
Last-Modified: Sun, 18 Feb 2007 02:12:10 GMT
ETag: "1758042-e-45d7b5fa;45e1f0e8"
Accept-Ranges: bytes
Content-Length: 14
Content-Type: text/plain; charset=utf-8

$ curl -I -H "Accept: image/png" "http://lilypond.org/doc/v2.10/input/test/lily-0c257c31dd"
HTTP/1.1 200 OK
Date: Sun, 15 Apr 2007 20:50:34 GMT
Server: Apache
Content-Location: lily-0c257c31dd.png
Vary: negotiate,accept,accept-charset,Accept-Encoding
TCN: choice
Set-Cookie: id=89.0.180.58.dynamic.barak-online.net.290801176670234596; path=/
Set-Cookie: id=89.0.180.58.dynamic.barak-online.net.290801176670234597; path=/
Last-Modified: Sun, 18 Feb 2007 02:12:27 GMT
ETag: "1758041-4c8-45d7b60b;45e1f0e8"
Accept-Ranges: bytes
Content-Length: 1224
Content-Type: image/png

[David Kilzer (:ddkilzer)]

When Firefox 2.0.0.3 requests the top-level URL, its Accept header is (via the livehttpheaders plug-in):

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

However, when it's requesting an image, its Accept header is:

Accept: image/png,*/*;q=0.5

Also worthy of note, when it requests the urchin.js JavaScript source, it uses an Accept header of:

Accept: */*

I wonder what MSIE 6/7 do in these cases?  What does Safari send via Foundation?

[David Kilzer (:ddkilzer)]

Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135) with a local debug build of WebKit r20896 sends this Accept header for the top-level request:

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

For the images (and for JavaScript source), it sends an Accept header of:

Accept: */*

[Alexey Proskuryakov]

See also: bug 9426; bug 12296 comment 5.

[Brady Eidson]

I think that, at the very least, we should match Firefox here, which would be a small change - the only difference we have from them is missing image/png for img resources.

However, we should also consider adding other image types before */*.  In addition to wanting to prefer tiff and jpg over gif, we might also want the Mac port to accept PDF as an image type since it's native to ImageIO.  Also, if someone has SVG Experimental support compiled in we should include SVG.

There's a great opportunity here, while we're looking at that, to make updates to all of our non-main-resource accept headers - there's a million mime types for javascript, and css has a well defined mime type we don't send either.

[David Kilzer (:ddkilzer)]

(In reply to comment #5)
> There's a great opportunity here, while we're looking at that, to make updates
> to all of our non-main-resource accept headers - there's a million mime types
> for javascript, and css has a well defined mime type we don't send either.

We should be careful not to stray too far from Firefox or MSIE 6/7, though.  That could create more problems than it solves.

[Nicholas Shanks]

bedison had put a dependancy on bug 12296 and then removed it, so i'll add it as a "see also" link here:
http://bugs.webkit.org/show_bug.cgi?id=12296

[Alexey Proskuryakov]

(In reply to comment #5)
> I think that, at the very least, we should match Firefox here, which would be a
> small change - the only difference we have from them is missing image/png for
> img resources.

As mentioned in related bugs, this would be a somewhat dangerous change, because Safari renders PNGs differently than Firefox does. 

[Brady Eidson]

So which bug is a better one to have - not showing any images at all, or having incorrect gamma on "advanced user" images?

Not trying to be sarcastic, I'm legitimately posing the question :)

[Alexey Proskuryakov]

It's also possible to fix this bug while preserving the preference for GIF and JPG over PNG (by adding those types to Accept, as well). Not sure if it's the right solution, though.

Playing with content negotiation headers may be inappropriate during stabilization - we've seen it before that seemingly innocuous changes to those broke sites, and even matching Firefox was not a guarantee of safety (e.g., some servers failed when seeing weights in Accept-Language header).

[Nicholas Shanks]

I still advocate that the best solution is to expose the Accept* headers to the enclosing application and not hard-wire them into WebKit. Safari can then offer the user the chance the set them (even if only via the Debug menu, rather than prefs).

I think this is the first step towards identifying what headers are most appropriate. I feel it is likely that there is no universally acceptable header, and some sites will break with one header, while others will break without it.

[Brady Eidson]

Nicholas - You say "still advocate" but I haven't heard mention of that idea til now.  That said, exposing accept headers through a WebKit SPI may very well be worth it - but that is a seperate issue that deserves a bug of its own to track.  Perhaps you could file that?  
However, this bugzilla and open source project is for WebKit, not Safari, so discussing UI/Preference changes in Safari here is inappropriate.

Alexey - I completely agree that "innocuous changes" can end up breaking unexpected things but I tend to think matching Firefox's behavior here would be a safe change to bake with for a little while.

[Brady Eidson]

A fact that hasn't been noted yet that I just confirmed with IE6 on Windows is that IE sends the same ACCEPT header as Firefox

[Alexey Proskuryakov]

(In reply to comment #12)

> Alexey - I completely agree that "innocuous changes" can end up breaking
> unexpected things but I tend to think matching Firefox's behavior here would be
> a safe change to bake with for a little while.

I certainly don't oppose that - in fact, I think that it would be a good thing to try post-stabilization! Whether it's OK now should probably be decided by people who made the call for stabilization in the first place :-)

[Brady Eidson]

in verbal discussions, I think Maciej has expressed that it will be a good idea - I will point him towards this bug to read the discussion and make the call  :)

[Darin Adler]

(In reply to comment #14)
> I certainly don't oppose that - in fact, I think that it would be a good thing
> to try post-stabilization! Whether it's OK now should probably be decided by
> people who made the call for stabilization in the first place :-)

That makes sense. I'm glad you're being both thoughtful and vigilant about this!

In this instance, I think you can make a strong case for doing this even during stabilization. The top two browsers by marketshare both have the same behavior and we can easily change ours to match. I think it's worth the small risk.

[Nicholas Shanks]

Brady wrote:
Nicholas - You say "still advocate" but I haven't heard mention of that idea
til now.  That said, exposing accept headers through a WebKit SPI may very well
be worth it - but that is a seperate issue that deserves a bug of its own to
track.  Perhaps you could file that?


I was referring to the discussion that took place regarding bug 3510, both on here and in IRC. My discussion of Safari was just an example of how the SPI could be exposed to the end user. Obviously it would be different in NetNewsWire, OmniWeb, Sandvox etc. I would be happy to use them as an example instead if you don't want Safari used on here. Just say the word.
I will also file a new bug explicitly requesting exposure of Accept* headers via an API.