824623 - Add image/svg+xml to the HTTP Accept header when fetching images

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[David Bruant]

I read on the Firefox bug regarding WebP [1] that web developers would love to use WebP, but can't because Firefox doesn't support it. Server-driven negociation could be a way out for them.
It's been suggested elsewhere [2] that the current HTTP Accept header for images in Firefox is suboptimal when it comes to server-driven negociation. The header currently says: "I accept png images... and any image... and any content". The image/* is somewhat misleading, because it could be misinterpreted as "webP accepted" which is plain false.

One idea would be to improve the header so that it reflects the actual capabilities user agent capabilities. This way, servers could implement server-driven negociation based on a useful header.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=600919
[2] http://www.igvita.com/2012/12/18/deploying-new-image-formats-on-the-web/

Comment 1

[David Bruant]

More complains about the unhelpful Accept header: http://www.webmonkey.com/2012/12/forget-javascript-its-time-for-browsers-to-speed-up-images/

Comment 2

[[Baboo]]

Bug 240493 would block this (it has been WONTFIXED though because being fait accompli), unless you consider SVG documents not to be be images.

Comment 3

[David Bruant]

(In reply to [Baboo] from comment #2)
> Bug 240493 would block this (it has been WONTFIXED though because being fait
> accompli), unless you consider SVG documents not to be be images.
https://bugzilla.mozilla.org/show_bug.cgi?id=240493#c57 and following sets the tone indeed.

"I have a bad feeling about this"... this is going to end up WONTFIX too. 


Regardless, I'd be interested in fully understanding why Accept-based negotiation is broken. HTTP introduced it for a good reason and if it failed, it's interesting to understand why and think about how HTTP2 could learn from that and maybe introduce an actual server-driven negotiation that hopefully won't break.

Comment 4

[David Bruant]

Wise words from Boris Zbarski
https://bugzilla.mozilla.org/show_bug.cgi?id=170789#c14
> If people want to send that crap over the web, fine.  But we should not ask them to.

Darin Finsher
https://bugzilla.mozilla.org/show_bug.cgi?id=170789#c15
> i agree, the Accept header says what we prefer to handle... it doesn't have to
> enumerate all the data types we do handle.

Agreed.


(In reply to [Baboo] from comment #2)
> Bug 240493 would block this (it has been WONTFIXED though because being fait
> accompli), unless you consider SVG documents not to be be images.
At the time, SVG support was bad. Current SVG support is much much better [1]. Also, the resolution comment [2] talks about the initial Accept header and not the header for images (different values are sent based on context since [3]), it wouldn't be absurd to add SVG to the list of the Accept header for image requests.

Given:
* "we shouldn't ask people to send crap"
* SVG isn't crap (since Mozilla spends quite some time improving its support, it's probably worthwhile)
* bug 240493 was WONTFIX'ed regarding because trying to introduce SVG in *all* accept requests

I'm repurposing the bug to something more specific. Applying the change only to images makes it not a duplicate of Bug 240493


[1] http://caniuse.com/#search=svg
http://www.w3.org/Graphics/SVG/Test/20110816/status/implementation_matrix.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=240493#c85
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=170789

Comment 5

[Robert Longson [:longsonr]]

It's just not granular enough. Should implementations that do some of SVG advertise SVG support in images if they don't support animation or don't support SVG fonts etc.

WONTFIX for this and all the reasons of bug 240493.

Comment 6

[David Bruant]

As someone said elsewhere, web devs have to test their website anyway. They'll figure out if a browser advertising itself as supporting SVG doesn't support it enough.

I've just found out that XHR supports setting the Accept header. Maybe a per application definition and use of the Accept header is a more appropriate way to go about this issue...

Comment 7

[DB30F97D]

Sorry, I just saw this here:

> the Accept header says what we prefer to handle...

I think you guys should read the RFC. The HTTP/1.1 specification clearly states that all of the Accept* headers specify what is "acceptable" by the client, i.e. everything that is not listed gets q=0.0, which means that something is "not acceptable". If no available variant of the resource matches an Accept* field with q>0.0, then no variant is acceptable and the 406 response is returned.
Preference is achieved by sorting the value of the q parameter.

> it doesn't have to enumerate all the data types we do handle.

It should.

Comment 8

[David Bruant]

(In reply to Tomasz Sobczyk from comment #7)
> > the Accept header says what we prefer to handle...
> 
> I think you guys should read the RFC. The HTTP/1.1 specification clearly
> states (...)
What the spec says doesn't matter much in a lot of occasions. If you read French, I recommend to read http://letrainde13h37.fr/11/les-technologies-web-et-leurs-standards/
Specs are nice documents, but too often written before what they describe is being exercised. There are a lot of such cases in HTTP/1.1
Apparently, the Accept header suffered from server misbehaving when receiving some values. Browsers had to make the decision to send close-to-useless Accept headers. Maybe for the best? Maybe the per-website thing with XHR is much better than a web browser-wise setting.


> > it doesn't have to enumerate all the data types we do handle.
> 
> It should.
If 4 major browsers all made the choice during at least 10 years to not do that, there is probably a good reason.

Web technologies are not a world of "the spec says what you should do". They're more a world of "there is a spec, but if websites break, web browsers will adapt regardless of what the spec says". How websites use the technology in the wild is MUCH more important than what the spec says. "MUCH more" as in "what the spec says doesn't matter" in some cases.

Comment 9

[patrck]

Accept headers sent by modern browsers when making a request for an image resource:

Chrome	
   */*

Safari	
   */*

Firefox	
   image/png,image/*;q=0.8,*/*;q=0.5

Internet Explorer 
   image/png,image/svg+xml,image/*;q=0.8, */*;q=0.5

Opera	
   text/html, application/xml;q=0.9, application/xhtml+xml, image/png, 
   image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

See: 
    http://www.igvita.com/2012/12/18/deploying-new-image-formats-on-the-web/