181368 - consider eliminating Accept-Charset and Accept-Language headers from image requests

Status: VERIFIED WONTFIX

(Core :: Networking: HTTP, defect, P5)

Description

[Darin Fisher]

it occured to me that we could probably eliminate the Accept-Charset and
Accept-Language headers from our image requests.  i wouldn't expect servers to
care about locale specific information when serving images.  they would probably
use different URLs if images needed to be localized (i.e., the HTML document
would be localized to reference different images).  of course i'm not sure how
to prove my theory, but eliminating these headers would cut back on a
significant number of bytes per request:

  Accept-Language: en-us,en;q=0.5\r\n
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n

that's 81 bytes by my count that most servers couldn't care less about.  thoughts?

Comment 1

[Bradley Baetz (:bbaetz)]

What about people doing text-as-image (or svg ;)?

Or 404s with a localised ErrorDocument?

Comment 2

[Darin Fisher]

>What about people doing text-as-image (or svg ;)?

imagelib currently barfs if it does not recognize the data as some type of image
format.  how does SVG work?  do we have a imagelib decoder for SVG or something?

>Or 404s with a localised ErrorDocument?

i don't follow... don't 404's usually result in a HTML document?  or are you
saying that websites serve up a 404 image that could be displayed inside a <img>
tag?  i suppose they could.  have you actually seen a website do this before?

BTW, i wouldn't be changing anything for toplevel image documents... i'm only
talking about inline images (<img> tags).

Comment 3

[Boris Zbarsky [:bzbarsky]]

>What about people doing text-as-image (or svg ;)?

I think by "text-as-image" Bradley meant a representation of some text in the
form of an image (eg scanned-in document).  If the original document is
available in multiple languages, for example, Accept-Language may make sense as
a result.

svg is not handled by imagelib at the moment, and really never should be (it
should just be embedded directly in the page).

Comment 4

[Bradley Baetz (:bbaetz)]

We don't have an imagelib for svg yet - note the ;)

bz: The svg spec requries it to be usable via <img>

If someone has an <img> link to a valid document with ahs a 200 return code (by
mistake) and then the user loads that document in a window, won't you get the
cached version, w-o accept lanugage? You could play games with the Vary header,
to detect that, I suppose, although this is an edge case.

Comment 5

[Darin Fisher]

hmm.. so maybe this bug should be closed then.  it seems wasteful to send these
bytes each-and-every when they are ignored 99% of the time.  oh well :(

if anyone has a convincing counter argument, please feel free to reopen.

Comment 6

[Bradley Baetz (:bbaetz)]

I was playing Devil's advocate ;)

I think we can drop Accept-Charset, though, since theres no charset for a
picture. Thats assuming that the caching I mentioned isn't an issue, though.

Comment 7

[Darin Fisher]

hmm... but SVG can be used to render text, right... so wouldn't the charset be
relevant to SVG content?

Comment 8

[Christopher Hoess (gone)]

Yeah, XML (including SVG) charsets are best delivered over HTTP.  They 
can be delivered in the XML declaration, but that's really just a refined 
version of the <meta http-equiv> kludge.

Comment 9

[John Unruh]

Verified wontfix per comments.