Last Comment Bug 125682 - Accept: HTTP header should be dynamically generated
: Accept: HTTP header should be dynamically generated
Status: RESOLVED WONTFIX
: helpwanted
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: x86 Linux
: -- enhancement with 14 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Patrick McManus [:mcmanus]
Mentors:
: 234170 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-15 03:59 PST by mop
Modified: 2015-12-14 17:29 PST (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description mop 2002-02-15 03:59:20 PST
There is a discussion in the svg newsgroup how to detect if mozilla is compiled
with svg. This can be achieved via js but that's not possible when you generate
pages dynamically via PHP or so. A solution could be the HTTP Accept Header.
This information is readable by Serverside scripts.

Peter Biesinger stated on the mozilla.svg newsgroup:

AFAIK it's impossible to change the accept line depending on
compilation options - Accept: contains either always SVG or
never SVG, which isn't useful. 

If that's the case this should be implemented.
Comment 1 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-15 08:36:13 PST
--> networking:http

btw, my name's christian biesinger, not peter biesinger

Comment 2 Christopher Hoess (gone) 2002-02-15 09:03:02 PST
This is probably a duplicate of bug 82526.  It sounds from the discussion there 
as if the Accept: header should be alterable at compile-time; see the patch in 
that bug for an idea of where to get started.
Comment 3 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-15 10:27:02 PST
choess, no. bug 82526 only puts a few different accept header strings in the JS
file, and depending on the request type one of them is chosen.
Comment 4 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-15 10:29:18 PST
changing owner to default owner of component, forgot that when I changed the
component
Comment 5 Christopher Hoess (gone) 2002-02-15 11:22:47 PST
->Gerv, who does Accept: header
Comment 6 Darin Fisher 2002-02-15 11:23:41 PST
there is very strong resistance against making the Accept header dynamic.  it
usually goes like so: "once you make the Accept header dynamic, there's a high
probability that it will grow in size, slowly degrading network performance."

this is why it is a static pref.  before making any changes to the Accept header
we try to carefully consider the performance (bloat) impact it might have and
weigh that against the potential gain.

that being said, i understand the situation w/ SVG.  since it is not always
available in mozilla builds, you need some way of telling the server if a
particular mozilla browser is SVG capable.

well, this does seem to be the purpose of the Accept header... i won't argue
that.  however, why is SVG optional?  or rather, for how long will it continue
to be optional?  will it ever be a regular part of mozilla?  will there come a
time when content providers can just assume that mozilla is SVG capable?  if so,
then i think we could put off modifying the Accept header until SVG becomes a
standard component of mozilla.
Comment 7 rpotts (gone) 2002-02-15 12:31:37 PST
Aren't we already going to make the Accept header 'dynamic' to allow image 
requests, linked JS, and linked style sheet requests to be more specific (and 
hence smaller) in their accept headers?

Comment 8 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-15 12:47:57 PST
rpotts, you seem to be talking about bug 82526.

But the patch in there only allows to change between different predefined
Accept: lines, all of which are hardcoded in the .js file. Thus, it doesn't
affect this bug.

Comment 9 Darin Fisher 2002-02-15 13:59:26 PST
rick: what christian said... by dynamic i think people mean programmable.  that
is, this bug seems to be about allowing an XPCOM component to dynamically add a
type to the default Accept header.
Comment 10 Gervase Markham [:gerv] 2002-02-15 14:07:41 PST
The Accept header should not be dynamic - but surely whoever builds the 
MathML/SVG nightly can tweak it by hand?

Gerv
Comment 11 Bradley Baetz (:bbaetz) 2002-02-15 16:03:21 PST
Hmm. If we fix bug 82526, then I don't think there would be an objection to
this, since the accept stuff would then be focussed.
Comment 12 Sören 'Chucker' Kuklau (gone) 2002-02-16 02:33:29 PST
Correct me if I'm wrong, but... if bug 82526 gets fixed, doesn't that mean that
SVG images only get the SVG mimetype(s) in their http accept headers? I think
that HTML and XML documents should get the SVG mimetype(s) too, because only
_that_ would - in my opinion - really solve the issue of detecting whether SVG
is enabled in the browser. (The .svg files - usually - aren't dynamic
themselves, but the .php / .cgi / ... files are. When the .php etc. files are
loaded though, Mozilla would _not_ indicate that it can do SVG.)
Comment 13 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-16 04:22:06 PST
Chucker: Um... how would Mozilla know if the requested object is an SVG image?
It does so after sending the request.
And the svg mimetype (application/svg+xml?) would definitely be added to the
normal accept header, maybe also the image one (which is sent for <img src>
requests), not sure about this.
Comment 14 Sören 'Chucker' Kuklau (gone) 2002-02-16 08:48:21 PST
chris: Oh, I thought the plan was to make image files get an accept header with
"image/gif, image/jpeg, ..., application/svg+xml", to make markup files get an
accept header with "text/html, text/css, etc.", etc., and nothing else.
Comment 15 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-16 08:56:21 PST
well, this is basically the plan, but you can't know if a file is a markup file
before you send the request. Thus, all supported formats should be included in
the initial Accept: header. Subsequent requests for things like <script src> or
<img src> or <link rel=stylesheet> should use a different accept header.
Comment 16 Sören 'Chucker' Kuklau (gone) 2002-02-16 09:08:06 PST
I see it now. Thanks.
Comment 17 GavinBrelstaff 2002-02-18 10:51:11 PST
*** This bug has been confirmed by popular vote. ***
Comment 18 Darin Fisher 2002-09-25 16:18:19 PDT

*** This bug has been marked as a duplicate of 170789 ***
Comment 19 Darin Fisher 2002-09-25 16:46:35 PDT
actually, this isn't a duplicate.  reopening.

i'd suggest marking this WONTFIX since this sort of feature can easily lead to
excessively long Accept headers which would kill page load times.
Comment 20 Georg Maaß 2002-09-26 09:44:54 PDT
> this sort of feature can easily lead to
> excessively long Accept headers which would kill page load times

You do not need to concat them to one large header value. Instead you can send
multiple equal named headers with different values and let Apache concat them.
Apache will concat them to one header with one single value, which is built by
concatenatin all values to one single value using semi colon space as sperator.

Because Apache does this for you, you do not need to concat all values to one
single huge value.
Comment 21 Gervase Markham [:gerv] 2002-09-26 09:54:39 PDT
Darin: it can only lead to long Accept: headers if the user has installed a
number of addons, all of which have a need to identify themselves to websites.
In this case, the user wants the addons to work, and so having the MIME types
added seems reasonable. 

Anyway, the actual number of such addons is really small - SVG is about the only
one I can think of. MathML used to be one, but it's now in the core. 

We don't want to fall into the "0, 1, many" fallacy - "if it's not zero or one,
it could be any number, and large numbers are bad, so let's not do it." On a 56k
modem, the additional time needed to send a MIME type of average length is 0.01
seconds (40 bytes at 4k/sec). It's not a killer.

Gerv 
Comment 22 Darin Fisher 2002-09-26 11:48:00 PDT
over a modem connection, the average MSS (TCP's maximum segment size) is 512 or
536 bytes.  using the cowtools page loader as an example, most HTTP requests are
just slightly above this limit.  that means that we send out two TCP packets for
every HTTP request.  if our HTTP headers were just slightly smaller, we'd end up
sending only one TCP packet.  this has an even greater impact when pipelining is
enabled, because pipelining allows several HTTP requests to be packed into one
TCP packet (think LAN/DSL where MSS is more like 1270 bytes).  each TCP packet
has some inherent overhead, including not just the additional bytes required by
the TCP/IP logic, but also by the various flow control algorithms present in TCP
like Nagle's algorithm that says only send the next packet if you've received
acknowledgement for the previous.  so the number of TCP packets has a very high
impact on page load performance.  trimming the Accept header as i've done in bug
 170789 helps reduce the size of image requests by a significant factor, which
should help average page load performance.
Comment 23 Mike Shaver (:shaver -- probably not reading bugmail closely) 2002-09-26 12:51:26 PDT
(
http://216.239.33.100/search?q=cache:-fuBm0JBIQkC:www.acm.org/sigcomm/ccr/archive/2001/jan01/ccr-200101-mogul.pdf+nagle+tcp&hl=en&ie=UTF-8
)

http://www.acm.org/sigcomm/ccr/archive/2001/jan01/ccr-200101-mogul.pdf has a
good explanation of Nagle, and why HTTP/1.1 implementations -- especially those
that use pipelining -- may well wish to disable it.  Many stacks expose that
capability -- do we make use of it?
Comment 24 Darin Fisher 2002-09-26 13:38:41 PDT
mike: i've actually done some limited testing w/ and w/o nagle's algorithm
(having read through that doc and others).  i found that in some cases disabling
nagle's algorithm hurts performance (over a high-speed LAN connection).  i need
to do more testing to see how it effects perforance over narrowband.  but
nagle's algorithm aside, there is also the TCP slow start algorithm that you
cannot disable.  that prevents sending more that the advertized congestion
window size (which is initialized to the MSS and doubles after each ACK).
Comment 25 Mike Shaver (:shaver -- probably not reading bugmail closely) 2002-09-26 13:43:29 PDT
I should well have guessed (shame on me), though your initial description of
Nagle sounded a bit off, so I'll use that as an excuse.

On Linux, the TCP_CORK stuff could keep us from sending a shorter-than-MSS
packet initially, if our pipelining buffering stuff doesn't already do so.  I
don't know if Windows or Mac have similar capabilities, or if, indeed, we
already create the pipelined request buffer before sending it tout ensemble.
Comment 26 Darin Fisher 2002-09-26 14:18:13 PDT
we create a flat buffer for the pipelined requests thus avoiding the need for
TCP_CORK (which is linux-only and would need to be ported).
Comment 27 Gervase Markham [:gerv] 2002-09-26 15:41:58 PDT
Darin: I buy what you're saying, and certainly am not arguing against your patch
to send more focussed Accept: headers for different types of request. But I
still think it's important for Image and "Main" to be configurable, because
there is a requirement there from the SVG folk. So, installing SVG may hurt
performance a little. Fair enough - extra capabilities always come at a cost.

Gerv
Comment 28 Bradley Baetz (:bbaetz) 2002-09-26 15:49:47 PDT
I think theres another bug somewhere on investigating using TCP_CORK, even for
non pipelined requests.
Comment 29 Gervase Markham [:gerv] 2002-11-24 14:17:37 PST
If anyone fixes this, it won't be me. :-|

Gerv
Comment 30 benc 2003-01-25 23:52:17 PST
back to defaults
Comment 31 Matthew Wilson 2003-12-06 03:17:43 PST
> Anyway, the actual number of such addons is really small - SVG is about the
> only one I can think of.

WML (wmlbrowser.mozdev.org) is an extension which would benefit from some behaviour.
Comment 32 Benjamin Smedberg [:bsmedberg] 2004-02-13 07:52:13 PST
*** Bug 234170 has been marked as a duplicate of this bug. ***
Comment 33 James Graham 2004-02-13 10:43:49 PST
Could someone add the word "header" to the summary, so this bug is easier to
find? I can't do it myself.

This problem has become more pronounced now that Camino is building without
MathML; this means that people are starting to detect Camino based on UA and
sending non-MathML content to Camino. That causes problems for anyone who wants
 to use MathML in Camino as they don't recieve MathML content even with a custom
build.

Where would one implement the fix to this bug? I can imagine a really hacky fix
that would run a script during the configure phase to update all.js or prefs.js
with a new Accept header based on the configuration options, but I guess that's
not close to being the right approach.
Comment 34 Mark Nottingham 2006-11-25 19:34:31 PST
Would it help to have a static whitelist of media types that, *if* a plug-in, compile-time component, whatever says they support, will show up? 

That way, it'll be possible for well-known formats like SVG, MathML, etc. to be supported dynamically, based on whether the browser's capabilities, while still controlling the number of media types that can be sent in the accept header?

Just thinking out loud...

Note You need to log in before you can comment on or make changes to this bug.