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
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
->Gerv, who does Accept: header
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. ***
*** This bug has been marked as a duplicate of 170789 ***
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.
> 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://18.104.22.168/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
back to defaults
> 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.
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...