httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17936] - Does not return HTTP 406 for restricted client Accept headers
Date Thu, 13 Mar 2003 16:00:05 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17936>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17936

Does not return HTTP 406 for restricted client Accept headers

freqout@speakeasy.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



------- Additional Comments From freqout@speakeasy.net  2003-03-13 16:00 -------
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message