- From: M. Hedlund <hedlund@best.com>
- Date: Wed, 1 Jan 1997 19:16:24 -0800 (PST)
- To: "Gregory J. Woodhouse" <gjw@wnetc.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 1 Jan 1997, Gregory J. Woodhouse wrote: > Hmm...now that I think about it, I just assumed that if the only > acceptable media type had a quality factor of 0.000, the server would be > required to return 406 Not Acceptable, but I don't see this spelled out. We talked about the meaning of q=0 a long time ago, but I don't see the issue resolved in the mailing list archives or minutes.[1] 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. 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. 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. Marc Hedlund <hedlund@best.com> [1] Two archive references dealing with the issue: <http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q1/0158.html> <http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q1/0225.html> And the IETF minutes that hint that it may have been discussed: <ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95apr/ area.and.wg.reports/app/http/http-minutes-95apr.txt> [2] <http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-07.txt>
Received on Wednesday, 1 January 1997 19:21:20 UTC