W3C home > Mailing lists > Public > public-swd-wg@w3.org > July 2007

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

From: Diego Berrueta <diego.berrueta@fundacionctic.org>
Date: Wed, 25 Jul 2007 12:36:33 +0200
To: SWD WG <public-swd-wg@w3.org>
Message-Id: <1185359793.4730.49.camel@duncan.fundacionctic.org>

I've run some additional tests. Find results below:

(Case e) [same as c&d, but without the q-values]
  Accept:                 application/rdf+xml,text/html
  Expected Content-Type:  application/rdf+xml
  Actual Content-Type:    text/html
  Result: FAILURE

(Case f)
  Accept:                 text/html,application/rdf+xml
  Expected Content-Type:  text/html
  Actual Content-Type:    text/html
  Result: Success

Some additional conclusions:

* Like cases (c) and (d), swapping the order of the rules in .htaccess
also inverts the results, i.e., (e) works fine, but (f) fails.

* I suspect the regular expressions can be refitted in order to make
cases (e) and (f) succeed at the same time. I have to work more on this
and, hopefully, I'll propose the necessary changes in the R.E.

* However, cases (c) and (d) are much more challenging due to the
presence of the q-values, and I still can't imagine how to fix them
using regular expressions.

* There are also other challenges, like MIME type masks with asterisks.
For instance, a request containg the following Accept header is valid
and should return HTML (text/html), but of course, it isn't matched by
our regular expressions:

   Accept: text/*

Regards,

El mié, 18-07-2007 a las 16:16 +0200, Diego Berrueta escribió:
> 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, 25 July 2007 10:37:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:29 GMT