Re: [Recipes] ISSUE-58: .htaccess 'accept header' ONLY responds to a header which EXACTLY matches \"application/rdf+xml\"

El mar, 17-07-2007 a las 12:12 +0000, SWD Issue Tracker escribió:
> "The recipe for responding to an accept header only responds to a header which
> EXACTLY matches "application/rdf+xml". However, a client may send (and often
> will) a header with many  comma-separated values, and they may have quality
> parameters (q=0.xx).
>
> This is a serious problem as people are copying the recipe, and making sites
> which do not work."

I made some testing on this issue using Vapour [1]. These are the
relevant results for Recipe 3 (Recipes 4 and 5 are similar). In all the
cases, a GET request was made for the [vocabulary|class|property] URI,
using a number of different values for the Accept header. I compared the
expected Content-Type against the actual Content-Type returned by the
server:

(Case a)
  Accept: application/rdf+xml;q=0.5
  Expected Content-Type: application/rdf+xml
  Actual Content-Type: application/rdf+xml
  Result: Success

(Case b)
  Accept: text/html;q=0.5
  Expected Content-Type: text/html
  Actual Content-Type: text/html
  Result: Success

(Case c)
  Accept: application/rdf+xml;q=0.3,text/html;q=.5
  Expected Content-Type: text/html (due to higher "q"-value)
  Actual Content-Type: text/html
  Result: Success

(Case d)
  Accept: application/rdf+xml;q=0.5,text/html;q=.3
  Expected Content-Type: application/rdf+xml (due to higher "q"-value)
  Actual Content-Type: text/html
  Result: FAILURE

My conclusions:

* Test cases (a) and (b) work fine because the regular expressions don't
have begin-of-line and end-of-line delimiters (i.e.: symbols ^ and $
respectively). Therefore, the additional ";q=0.5" substring at the end
of the Accept header is silently skipped.

* Test case (c) works fine because of the order of the RewriteRule
sentences in the .htaccess file. The first rule (the one that matches
any Accept header that contains 'text/html') has precedence, so the
appropiate redirection is returned.

* Unfortunately, test case (d) fails for the same reason. The first rule
produces an undesired match and shadows the second one. The values of
the "q" parameters are opaque to the regular expression.

* If we swap the order of the RewriteRules in the .htaccess, then (d)
will succeed, but (c) will fail.

* As TimBL said, there is a serious problem, because content negotiation
is not working properly. We fail to deliver the preferred content-type
even if it is actually available! (see case (d)).

* It seems to me that this issue cannot be easily solved with the
current regex approach, due to the inability of the regex to compare
numerical values (AFAIK). In practical terms, the list of MIME types
cannot be ordered by their "q"-value.

I hope I'm not missing anything. Creative ideas on how to fix this issue
would be greatly appreciated!

[1] http://vapour.sourceforge.net/


-- 
Diego Berrueta
R&D Department  -  CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Científico Tecnológico Gijón-Asturias-Spain
www.fundacionctic.org

Received on Wednesday, 18 July 2007 14:16:45 UTC