Bug 17937 - Does not return HTTP 406 for restricted client Accept headers
Summary: Does not return HTTP 406 for restricted client Accept headers
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_negotiation (show other bugs)
Version: 2.0.44
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2003-03-12 22:35 UTC by FreqOut
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description FreqOut 2003-03-12 22:35:20 UTC
There is a bug in the mod_negotiation module of Apache httpd where it is 
incorrectly returning HTTP status 200 and content when receiving a browser 
client request that contains restricted Accept headers, when the correct web 
server response should be a HTTP status 406.

For example using the HTTP client request header of

GET /images/asf_logo_wide.gif HTTP/1.1
User-Agent: Mozilla/4.0 [en] ()
Accept: text/*
Connection: keep-alive
Host: www.apache.org

(note www.apache.org is a 2.x based server, but this defect does apply to 
1.3.27 and other 1.3.x versions)

The httpd web server should return a HTTP STATUS 406 because the .gif is 
associated with image/gif and does not match the HTTP client's Accept 
criteria.  Instead, Apache httpd currently responds with a HTTP STATUS 200 with 
the gif file's binary content.

Associated references:
HTTP 1.1, rfc2616 Section 14
and Apache negotiation algorithm in
Comment 1 FreqOut 2003-03-12 22:37:32 UTC
Related Apache httpd-1.3.x based bug # 17936
Comment 2 André Malo 2003-03-12 23:10:29 UTC
You're requesting a non-negotiated resource. Therefore negotiation rules don't
Comment 3 FreqOut 2003-03-13 16:00:37 UTC
Andre, I'm afraid you'll have to go into more detail concerning non-negotiated 
resource.  There is no mention of non-negotiated resources in either RFC 2616 
or the Apache content negotiation documentation.  If you could point me towards 
documentation, or show me an example where Apache correctly returns the 406, 
that would be really helpful.

I would also like to point out the Apache negotiation documentation concerning 
this issue.
-------------------------< SNIP >-------------------------------------------
Apache Negotiation Algorithm
Apache can use the following algorithm to select the 'best' variant (if any) to 
return to the browser. This algorithm is not further configurable. It operates 
as follows:

First, for each dimension of the negotiation, check the appropriate Accept* 
header field and assign a quality to each variant. If the Accept* header for 
any dimension implies that this variant is not acceptable, eliminate it. If no 
variants remain, go to step 4. 
Select the 'best' variant by a process of elimination. Each of the following 
tests is applied in order. Any variants not selected at each test are 
eliminated. After each test, if only one variant remains, select it as the best 
match and proceed to step 3. If more than one variant remains, move on to the 
next test. 
Multiply the quality factor from the Accept header with the quality-of-source 
factor for this variant's media type, and select the variants with the highest 
Select the variants with the highest language quality factor. 
Select the variants with the best language match, using either the order of 
languages in the Accept-Language header (if present), or else the order of 
languages in the LanguagePriority directive (if present). 
Select the variants with the highest 'level' media parameter (used to give the 
version of text/html media types). 
Select variants with the best charset media parameters, as given on the Accept-
Charset header line. Charset ISO-8859-1 is acceptable unless explicitly 
excluded. Variants with a text/* media type but not explicitly associated with 
a particular charset are assumed to be in ISO-8859-1. 
Select those variants which have associated charset media parameters that are 
not ISO-8859-1. If there are no such variants, select all variants instead. 
Select the variants with the best encoding. If there are variants with an 
encoding that is acceptable to the user-agent, select only these variants. 
Otherwise if there is a mix of encoded and non-encoded variants, select only 
the unencoded variants. If either all variants are encoded or all variants are 
not encoded, select all variants. 
Select the variants with the smallest content length. 
Select the first variant of those remaining. This will be either the first 
listed in the type-map file, or when variants are read from the directory, the 
one whose file name comes first when sorted using ASCII code order. 
The algorithm has now selected one 'best' variant, so return it as the 
response. The HTTP response header Vary is set to indicate the dimensions of 
negotiation (browsers and caches can use this information when caching the 
resource). End. 
To get here means no variant was selected (because none are acceptable to the 
browser). Return a 406 status (meaning "No acceptable representation") with a 
response body consisting of an HTML document listing the available variants. 
Also set the HTTP Vary header to indicate the dimensions of variance.
-------------------------< SNIP >-------------------------------------------

Following the negotiation algorithm above (and I must say kudos to Apache for 
providing this document) you do step 1, in which you discover that there is no 
maching Accept type, and must go to step 4, which states that a 406 should be 

Comment 4 FreqOut 2003-03-13 18:29:16 UTC
I'll allow this bug to remain RESOLVED - INVALID, while the issue is discussed 
in 17936.