<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Assignee

Comment 1

•

26 years ago

the request for http://starwave.com/starwavelogo.jpg fails w/ a 406 (Not acceptable) response from the server. This means that the client is sending unacceptable Accept: headers to the server for this particular resource. The three images are as follows: http://starwave.com/starwavelogo.jpg http://starwave.com/infoseeklogo.gif http://starwave.com/GOw_82x82.gif In apprunner, all of these image requests get 406 responses. In Comm. they all are loaded appropriately.

Assignee

Comment 2

•

26 years ago

This is the most anal http server I've ever seen. It's requiring that you send accept headers for everything you can handle. It only defaults text/html. I added "accept: */*" to the request headers and it works. Gagan, Have we come up w/ an accept strategy yet?

Assignee

Updated

•

26 years ago

Status: NEW → RESOLVED

Closed: 26 years ago

Resolution: --- → FIXED

Assignee

Comment 3

•

26 years ago

Our accept strategy is that we're ending the debate about what to send and we're just sending "accept: */*". MIME based content negotiation is long since dead. Adding fur to the cc list as he's got my back (so I'm told by an un-named 3rd party). I checked in the default accept header an hour or two ago, 9/10/99 noon pac time. Jud

Comment 4

•

26 years ago

The older versions of NN send different accept headers for images than for other HTTP GET operations. I can't remember exactly what the headers were, but they were something like, "Accept:image/gif;image/jpeg;image/pjpeg;image/png". Jud's right in that I have never heard of a single server that did anything useful with accept headers, which is not to say they don't exist. I guess we can wait until beta to see if anyone screams bloody murder.

Assignee

Comment 5

•

26 years ago

*** Bug 12790 has been marked as a duplicate of this bug. ***

Comment 6

•

26 years ago

Raaaaahhhh ! Bloody Murder !!!! OK, there's at least one HTTP server out which does some very usefull thing swith the HTTP accept: W3C jigsaw WWW server has a feature called "negotiation". This can be used to deliver PNG or GIF (if the browser supports PNG, it gets PNG - if GIF is the only supported image type, GIF is delivered) - negotiation based on the "Content-Type". Or the server sends you the german version of a document if the browser is a german version, otherwise the english is send - negotiation based on the "Content-Language"... (In our institute, we're using the language negotiation; content negotiation is used to check whether the client supports XML or not. If XML is supported, the browser gets XML/CSS2, otherwise a XML->HTML-converter is called first to translate the data). Fix the headers - or don't announce that Mozilla is standard-conformat... =:-) Implementation: Best implementation would be to enumerate all supported file types (plugins included) in the ACCEPT:-header. But this may waste the header, therefore I offer an easy compromise: Each plugin (&& supported filetype) gets a boolean whether it should be put into the ACCEPT: header of not; the user can set/unset this boolean with the prefs.

Comment 7

•

26 years ago

First, let me point out that Accept headers are optional - no HTTP client is required to send them in either the 1.0 or 1.1 RFC, nor are there specifications that indicate how the client should choose the MIME types in those headers. So, our job is to figure out what the default behavior of Mozilla should be with regards to these headers, taking into account precedent, among other things. Adding preferences to fine-tune the default behavior, as you suggest, is OK, but isn't nearly as important as determining the best baseline behavior. As far as the idea of sending a MIME type for every installed plugin, I think that could potentially generate enormous HTTP GET requests. I just took a quick look at my Communicator installation and I have 20+ plugins installed, some of which handle multiple MIME types. In addition, I have viewers registered for nearly 80 additional MIME types. (On Windows, applications often register themselves as viewers, e.g. MS Word registers a viewer for application/x-msword.) Transmitting all those MIME types in the headers would probably add an extra 1.5 KB to every HTTP request. Multiply those bytes by all the people using the browser and all the number of times they click on a link. How many people will benefit from all those transmitted terabytes ? Not many, I say. MIME Accept headers are rarely employed for content negotiation. In four years of working at this company, yours is the very first case I've heard of them being deployed. (I'm not talking about Accept-language, which is more commonly used.) This is in part because existing browsers play fast and loose with Accept headers, so they can't be counted on as a reliable source of client preferences. On the other hand, servers frequently inspect the user-agent string to choose which page to transmit to the client. The most common use of this is to serve different pages to Netscape and IE users. Using the user-agent for this purpose is, admittedly, not ideal because the release of new browsers tends to result in undesirable behavior; Recently we've had problems with some sites that won't serve the correct content to Mozilla because they don't recognize its 5.0 user-agent string.

Comment 8

•

26 years ago

> First, let me point out that Accept headers are optional - > no HTTP client is required to send them in either the 1.0 or > 1.1 RFC, nor are there specifications that indicate how the > client should choose the MIME types in those headers. So, > our job is to figure out what the default behavior of > Mozilla should be with regards to these headers, taking into > account precedent, among other things. Adding preferences > to fine-tune the default behavior, as you suggest, is OK, > but isn't nearly as important as determining the best > baseline behavior. > > As far as the idea of sending a MIME type for every > installed plugin, I think that could potentially generate > enormous HTTP GET requests. Therefore I wrote that this should be _optional_, based on a boolean in the prefs. You're right, enumerating all supported mime types (of CDE 1.e etc.) would bomb-out many networks... But sending "important" mime-types would be usefull... Question is: "What is important ?" ---- > I just took a quick look at my > Communicator installation and I have 20+ plugins installed, > some of which handle multiple MIME types. In addition, I > have viewers registered for nearly 80 additional MIME types. > (On Windows, applications often register themselves as > viewers, e.g. MS Word registers a viewer for > application/x-msword.) > Transmitting all those MIME types in the headers would > probably add an extra 1.5 KB to every HTTP request. > Multiply those bytes by all the people using the browser and > all the number of times they click on a link. How many > people will benefit from all those transmitted terabytes ? > > Not many, I say. MIME Accept headers are rarely employed > for content negotiation. In four years of working at this > company, yours is the very first case I've heard of them > being deployed. As I said, it's a feature we found in W3C's jigsaw, and we figured out that the feature is VERY usefull in cases where many different (old) browsers are used... ---- > (I'm not talking about Accept-language, > which is more commonly used.) This is in part because > existing browsers play fast and loose with Accept headers, > so they can't be counted on as a reliable source of client > preferences. Mhhh, we hadn't any problems with Netscape 4.x, lynx and Hotjava 1.1.5 and content negotiation... ---- > On the other hand, servers frequently inspect the user-agent > string to choose which page to transmit to the client. The > most common use of this is to serve different pages to > Netscape and IE users. Using the user-agent for this > purpose is, admittedly, not ideal because the release of new > browsers tends to result in undesirable behavior; Recently > we've had problems with some sites that won't serve the > correct content to Mozilla because they don't recognize its > 5.0 user-agent string. Therefore using the single ACCEPT*:-headers would be more usefull - if they won't contain rubbish... nor nothing =:-)

Comment 9

•

26 years ago

> Therefore I wrote that this should be _optional_, based on a boolean in the > prefs. You're right, enumerating all supported mime types (of CDE 1.e etc.) > would bomb-out many networks... > But sending "important" mime-types would be usefull... Well, this probably wouldn't be a "pref" in the sense that an individual user would modify it to get the behavior they want. After all, what would be the point of a CGI author adding content-negotiation if, to get it right, each individual user had to know how to change some obscure setting in Mozilla. Second, as you say, who decides when a MIME type is "important" and who ranks them ? You can't leave it to the plugin vendor - they all think that *their* MIME type is the most important. It's a huge political football you would be throwing out there. > Mhhh, we hadn't any problems with Netscape 4.x, lynx and Hotjava 1.1.5 and > content negotiation... Try IE3 or IE2. I can't remember which, but one of these sends wildcard Accept headers.

Comment 10

•

26 years ago

>> Therefore I wrote that this should be _optional_, based on a boolean in the >> prefs. You're right, enumerating all supported mime types (of CDE 1.e etc.) >> would bomb-out many networks... >> But sending "important" mime-types would be usefull... > >Well, this probably wouldn't be a "pref" in the sense that an individual user >would modify it to get the behavior they want. But it should be accessible to the user. Please !!!! ---- >After all, what would be the >point of a CGI author adding content-negotiation if, to get it right, each >individual user had to know how to change some obscure setting in Mozilla. >Second, as you say, who decides when a MIME type is "important" and who ranks >them ? You can't leave it to the plugin vendor - they all think that *their* >MIME type is the most important. It's a huge political football you would be >throwing out there. Let's play football !! =:-) The problem is: The current state is inaceptable ! :-( Any good idea how to fix this ? ---- Best solution would be if there would be another handshaking-protocol in HTTP: CGI/Servlet delivers the content-types available, and browser selects the first/best matching one... (something for HTTP 1.2 :-) ---- >> Mhhh, we hadn't any problems with Netscape 4.x, lynx and Hotjava 1.1.5 and >> content negotiation... > >Try IE3 or IE2. I can't remember which, but one of these sends wildcard Accept >headers. Yes, and Netscape adds a (stupid) */* at the end of the list. I had to hack into jigsaw to remove this. The only browsers which sets this correctly are HotJava and Lynx, both set */*;q=0.01 BTW: Lynx accept-list: accept: text/html, text/plain, application/postscript, audio/x-pn-realaudio, application/octet-stream, text/sgml, video/mpeg, im age/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01 Long, isn't it ?? :-) For IE2 and IE3 I hacked up a "default" ACCPET list in jigsaw's NegotiationFrame which is added after the returned response header. BTW: Maybe I'm wrong, but in HTTP 1.1. the accept:-header is nopt send for each GET etc., isn't it ?

Comment 11

•

26 years ago

> Best solution would be if there would be another handshaking-protocol in HTTP: > CGI/Servlet delivers the content-types available, and browser selects the > first/best matching one... > (something for HTTP 1.2 :-) Exactly this feature is already a part of HTTP 1.1. I think it's referred to simply as "client-side content negotiation". The disadvantage is that it requires another server round-trip. > For IE2 and IE3 I hacked up a "default" ACCPET list in jigsaw's NegotiationFrame > which is added after the returned response header. So, it sounds as if you too are using user-agent information to do content negotiation, same as most other sites. > BTW: Maybe I'm wrong, but in HTTP 1.1. the accept:-header is not send for each > GET etc., isn't it ? You mean in pipelining mode ? I don't know, but I would hope not.