Closed Bug 125682 Opened 23 years ago Closed 9 years ago

Accept: HTTP header should be dynamically generated

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mop, Unassigned)

References

Details

(Keywords: helpwanted) 

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.
--> networking:http

btw, my name's christian biesinger, not peter biesinger
Component: Browser-General → Networking: HTTP
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.

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.

changing owner to default owner of component, forgot that when I changed the
component
Assignee: asa → darin
QA Contact: doronr → tever
->Gerv, who does Accept: header
Assignee: darin → gerv
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.
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?


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.


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.
The Accept header should not be dynamic - but surely whoever builds the 
MathML/SVG nightly can tweak it by hand?

Gerv
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.
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.)
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.
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.
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.
I see it now. Thanks.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

*** This bug has been marked as a duplicate of 170789 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
> 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.
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 
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.
(
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?
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).
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.
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).
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
I think theres another bug somewhere on investigating using TCP_CORK, even for
non pipelined requests.
If anyone fixes this, it won't be me. :-|

Gerv
Assignee: gerv → nobody
Status: REOPENED → NEW
Keywords: helpwanted
back to defaults
Assignee: nobody → darin
QA Contact: tever → httpqa
Summary: HTTP Accept Header should be dynamically generated → Accept : should be dynamically generated
> 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.
*** Bug 234170 has been marked as a duplicate of this bug. ***
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.
Summary: Accept : should be dynamically generated → Accept : header should be dynamically generated
Summary: Accept : header should be dynamically generated → Accept: HTTP header should be dynamically generated
Assignee: darin → nobody
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...
Status: NEW → RESOLVED
Closed: 22 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.