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

Hi Diego,

Sorry for confusion in teleconference today. I should have read this email first, you've summarised the problem very clearly.

Yes, as far as I know, taking account of the q-values would require a completely different approach to the server configuration.

Last year I experimented with using type-map files (.var), but found the necessary configuration quite complicated. Both internal and external rewrites were required in addition to the type-map file, in order to achieve conditional redirects. 

Cheers,

Al.

--
Alistair Miles
Research Associate
Science and Technology Facilities Council
Rutherford Appleton Laboratory
Harwell Science and Innovation Campus
Didcot
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman

Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440  

> -----Original Message-----
> From: public-swd-wg-request@w3.org 
> [mailto:public-swd-wg-request@w3.org] On Behalf Of Diego Berrueta
> Sent: 18 July 2007 15:16
> To: SWD WG
> Cc: Tim Berners-Lee
> Subject: 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 Tuesday, 24 July 2007 16:43:50 UTC