|Summary:||never gives 300 multiple choices|
|Product:||Apache httpd-2||Reporter:||Christoph Anton Mitterer <calestyo>|
|Component:||mod_negotiation||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Christoph Anton Mitterer 2013-08-17 21:34:19 UTC
Hi. There seems to something fishy with the static negotiation algos for languages/mime types etc. Sending Accept: image/gif while having file.png file.jpeg correctly gives the 406 with the HTML and a list of alternatives Sending Accept: image/png, image/jpeg while having file.png file.jpeg though, gives the jpeg (as this is smaller). Well while this may be reasonable for some people, it breaks standards as one should probably get the 300 mutliple choices. So apache needs a flag to allow having standards compliant behaviour, i.e. something like ForceLanguagePriority. But now, hen setting ForceLanguagePriority none which should be the default btw, as all others more or less break the RFCs. one also doesn't get at 300. E.g. sending Accept: en, de while having file.en.txt file.de.txt again gives the smaller of the two. Accept: fr would again give a correct 406 Interestingly, having: Accept: fr while having file.en.txt file.de.txt file.gif returns the GIF... I'm not sure whether this breaks standards,... but definitely sounds like a bad thing. Cheers, Chris.
Comment 1 Eric Covener 2013-08-17 22:44:07 UTC
(In reply to Christoph Anton Mitterer from comment #0) > Hi. > > > There seems to something fishy with the static negotiation algos for > languages/mime types etc. > > Sending > Accept: image/gif > while having > file.png > file.jpeg > correctly gives the 406 with the HTML and a list of alternatives > > Sending > Accept: image/png, image/jpeg > while having > file.png > file.jpeg > though, > gives the jpeg (as this is smaller). > > Well while this may be reasonable for some people, it breaks standards as > one should probably get the 300 mutliple choices. Can you include references to the spec requirements broken here? From a quick check, mod_negotiation only sends 300s when the browser sends a Negotiate: header (rfc2296), among other conditions. I could not find anything in 2616 with a requirement or suggestion to do client-driven negotiation / send 300.
Comment 2 Christoph Anton Mitterer 2013-08-17 23:24:55 UTC
Hey Eric... Well... 1) We definitely have some documentation problem as https://httpd.apache.org/docs/current/mod/mod_negotiation.html#forcelanguagepriority implies 300 would be sent if it is set to None... But actually, what I just found out,... if it is set to None... it will simply not use LanguagePriority but rather fall back to the other steps in the Apache algo (e.g. smalles file, alphabetically first, etc.) if multiple possibilities remain. 2) The main idea of this request was: implement some flag, that actually makes Apache give 300's back, if there are multiple choices... i.e. not following the "Apache algo"... 3) Why breaking the RFC... well I'd simply say the existence of the 300 mutiple choices status already implies that it should be used for that. Of course, the reality is that the browsers are broken, e.g. they usually never send "*" as an accepted language... thus webservers came along with things like the fallback... and now no one gives up... So I guess you cannot simply drop the "legacy" behaviour... but regardless of whether it's a strict RFC breakage or not (respectively whether it "just" breaks the intentions of the RFC)... users should at least have the possibility to get the behaviour that if nothing matches what the client explicitly specified as Accept, Accept-Language, etc. ... he'll get at 406 (that already works, well at least for MIME type and language).... and if there are multiple equal matches, a 300.
Comment 3 Christoph Anton Mitterer 2013-08-18 00:12:28 UTC
wrt 1) Wrong documentation about 300s is also found here: https://httpd.apache.org/docs/current/content-negotiation.html#better
Comment 4 Eric Covener 2013-08-18 01:50:52 UTC
(In reply to Christoph Anton Mitterer from comment #3) > wrt 1) Wrong documentation about 300s is also found here: > https://httpd.apache.org/docs/current/content-negotiation.html#better You'll have to elaborate (universal diff is best). You may also want to split your bug report from the enhancement request.
Comment 5 Eric Covener 2013-08-18 01:54:41 UTC
AFAICT, The format of the 300 response is not defined by HTTP/1.1, so Apache requires that the client signal it understands the subsequent (abandoned?) transparent renegotiation related RFCs. I assume that to get someone interested in adding some other mechanism (or output format?) for the 300 response, some more context would be needed to justify/test its usefulness.
Comment 6 Christoph Anton Mitterer 2013-08-18 15:58:28 UTC
Hey Eric. WRT to the diffs thingy... until now I always found it hard to contribute with such minor improvements to the documentation, as you were using SVN, but I just saw there is also a git repo for httpd at Github? Is someone taking care on pull requests there, and is that kept in sync with SVN? That way it would be much easier to propose you guys some small changes and see whether they got merged without making one big patch to the documentation,.. which may in the end be rejected.