Re: A broken browser

On Wed, 1 Jan 1997, M. Hedlund wrote:

[...]
> 
> So, what should it be?  It's pretty obvious that a Web browser sending q=0
> for text/html is broken and not really trying to say that it doesn't want
> HTML.  (The funny thing is that this configuration reportedly is caused by
> compiling Lynx on SGI with the optomization flag on.  I suppose you could
> argue that a browser that won't accept HTML is very highly optomized
> indeed.)  But there are cases where a browser would want to say it doesn't
> want something -- say, I don't have a postscript printer, so don't send me
> postscript.  Acknowledging that the Lynx bug is not a good example of the
> need, I think saying q=0 SHOULD be interpreted as "this media type is not
> acceptable" would be right.
> 
> However, I disagree that the spec simply doesn't spell this out but does
> imply it (as you seem to suggest).  Section 3.9 says that q values merely
> indicate relative preference, rather than absolute quality.  Under that
> definition, q=0 would mean, "This is the least desirable media type of the
> media types listed in the Accept header."  Therefore, I interpret the
> current spec to say that a server is never required to send a 406 if the
> client sends _any_ q value with an available media type in the Accept
> header. 
> 

Well, my take on it is that it there are two or more matching media types,
then the one with the greater quality factor should be used. If there is
only one, and it has q=0.000, then it's really not obvious what the correct
beavior is simply because there is nothing with a greater quality factor.

> In other words, the only time a 406 should appear is if the client sends an
> Accept header without any listing of media types available to fulfill the
> request:
> 	- Browser sends Accept: text/html, image/gif
> 	- Server has image/jpeg only; responds with 406.
> Since most browsers send '*/*' as part of the Accept header, 406's should
> be extremely rare.
> 

Actually, this isn't quite true because more specific media types override
more general ones. In this particular case */*;q=0.001 is overriden by
text/html;q=0.000.

> This interpretation is explicitly supported by the following, from the
> current draft[2]:
> 
> --- begin ---
> 
> 10.4.7 406 Not Acceptable [...]
>   Note: HTTP/1.1 servers are allowed to return responses which are
>   not acceptable according to the accept headers sent in the request.
>   In some cases, this may even be preferable to sending a 406
>   response. 
> 
> --- end ---
> 
> I would suggest that section 3.9 be revised to say that q=0 SHOULD be
> interpreted as an indication that the client does not want a response
> entity of the indicated type.  Alternatively, the interpretation given
> above could stand as long as it is made explicit that a media type not
> listed in the Accept header would be unacceptable -- but that would
> completely break any browser that doesn't send Accept headers.
> 

I was going to disagree, but I think you are right. How would you configure
a browser to accept any kind of text but HTML (I agree, a very strange
thing to do)? The only way I can think of to do it is with

Accept: text/*, text/html;q=0.000

So it seems that q=0.000 does not necesarily indicated a configuration
error (as it does in this case). In fact, I think I'd support your proposed
language, but I'd change SHOULD to MUST. Actually, if there's an
alternative method for excluding specific subtypes, I'd go with SHOULD;
otherwise, I'd go with MUST.


> Marc Hedlund <hedlund@best.com>
> 
[...]
---
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

Received on Wednesday, 1 January 1997 20:01:18 UTC