Related Apache httpd-2.x based bug # 17937

You're requesting a non-negotiated resource. Therefore negotiation rules don't
apply.

Thanks for your care anyway and thanks for using Apache.

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 
value. 
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 
returned.

I know the docs ;-)

But it's a simple answer: mod_negotiation is not involved in the request.
Multiviews apply, if and only if the requested resource does not map exactly to
a file (or directory), i.e. if the server would return a 404 otherwise (also
described in the docs somewhere)
type maps apply if the requested (existing) file is handled by the type-map handler.

So if you're explicitely requesting an existing resource, which isn't magically
negotiated (type-maps), mod_negotiation feels not responsible for the request.
No bug.

This is, by the way, the only way it can work. Consider, for example, the
following situation:

- request with Accept: something
-> response 406 with a list of available variants.
-> user explicitely selects one variant but _doesn't_ change his Accept-Header
-> response 406? no. ignore Accept-Header, because it is an explicitely
requested resource which has no alternative variants.

Thank you for your quick response André.
Ongoing, I'll just update this bug rather than have us go back and forth with 
the same stuff on both bugs.  17937 references this bug, and that is enough.

Your premise is that negotiation will not be invoked if there exists only one 
resource for the requested file, and that the correct thing would be to return 
the requested file, disregarding the client's Accept headers.  It would help me 
to accept this, if you could show some public documentation that would back 
this type of response.  I have done my best to comb through relevant 
documentation, and to do searches for non-negotiation criteria.

I'm going to take some time to research this some more, while also discussing 
it with others.  I'm afraid that I'm still not convinced that Apache httpd is 
exhibiting the correct behavior.  Although, I will submit that I have seen both 
behaviors in other web servers.  IIS does return a HTTP 406, and I admit that 
that does not make it "correct".  Apache Tomcat (coyote) does the same as 
Apache httpd, but coming from the same group that is not a surprise.  However, 
when this is compounded by SUN's Enterprise web server also not returning a 
HTTP 406, I must then be able to supply further evidence that would support 
returning HTTP 406 in this case.

Ok André, I made your case for you.

According to rfc2616
-----------------------------< snip >--------------------------------------
10.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities which have content characteristics not acceptable
   according to the accept headers sent in the request.

   Unless it was a HEAD request, the response SHOULD include an entity
   containing a list of available entity characteristics and location(s)
   from which the user or user agent can choose the one most
   appropriate. The entity format is specified by the media type given
   in the Content-Type header field. Depending upon the format and the
   capabilities of the user agent, selection of the most appropriate
   choice MAY be performed automatically. However, this specification
   does not define any standard for such automatic selection.

      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. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

   If the response could be unacceptable, a user agent SHOULD
   temporarily stop receipt of more data and query the user for a
   decision on further actions.
-----------------------------< snip >--------------------------------------

The important part there is the "Note:", where it does specify that a server is 
allowed to return the resource even though it does not match the Accept header, 
and thus it is left up to the client to reject the resource based on the 
returned headers which hopefully will send the correct content type.

I still think this is an unfortunate flaw in the specification, but I agree 
that is cannot be considered a Apache httpd flaw, only an implementation choice.

Thanks for your update. I think we can safely close that bug now :)