Bug 13355 - Images on lilypond.org do not load because they expect an Accept: header with image/png
Summary: Images on lilypond.org do not load because they expect an Accept: header with...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://lilypond.org/doc/v2.10/Documen...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-15 12:36 PDT by Moshe Dror
Modified: 2007-04-17 15:22 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moshe Dror 2007-04-15 12:36:23 PDT
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
Comment 1 mitz 2007-04-15 14:03:37 PDT
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
Comment 2 David Kilzer (:ddkilzer) 2007-04-15 17:21:10 PDT
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?

Comment 3 David Kilzer (:ddkilzer) 2007-04-15 17:33:29 PDT
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: */*

Comment 4 Alexey Proskuryakov 2007-04-16 10:46:53 PDT
See also: bug 9426; bug 12296 comment 5.
Comment 5 Brady Eidson 2007-04-16 11:56:39 PDT
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.
Comment 6 David Kilzer (:ddkilzer) 2007-04-16 12:09:21 PDT
(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.

Comment 7 Nicholas Shanks 2007-04-16 12:19:40 PDT
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
Comment 8 Alexey Proskuryakov 2007-04-16 13:13:06 PDT
(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. 
Comment 9 Brady Eidson 2007-04-16 13:25:49 PDT
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 :)
Comment 10 Alexey Proskuryakov 2007-04-16 21:52:45 PDT
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).
Comment 11 Nicholas Shanks 2007-04-17 03:16:25 PDT
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.
Comment 12 Brady Eidson 2007-04-17 10:40:09 PDT
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.
Comment 13 Brady Eidson 2007-04-17 10:54:14 PDT
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
Comment 14 Alexey Proskuryakov 2007-04-17 10:58:42 PDT
(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 :-)
Comment 15 Brady Eidson 2007-04-17 11:29:38 PDT
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  :)
Comment 16 Darin Adler 2007-04-17 11:56:05 PDT
(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.
Comment 17 Nicholas Shanks 2007-04-17 15:22:23 PDT
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.