bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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




Networking: HTTP
16 years ago
7 years ago


(Reporter: Darin Fisher, Assigned: Darin Fisher)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [snap])



16 years ago
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?


16 years ago
Severity: normal → trivial
Priority: -- → P5
Whiteboard: [snap]
Target Milestone: --- → mozilla1.3alpha
What about people doing text-as-image (or svg ;)?

Or 404s with a localised ErrorDocument?

Comment 2

16 years ago
>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).
>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).
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

16 years ago
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.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
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

16 years ago
hmm... but SVG can be used to render text, right... so wouldn't the charset be
relevant to SVG content?
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

16 years ago
Verified wontfix per comments.
QA Contact: httpqa → junruh
You need to log in before you can comment on or make changes to this bug.