No additional notes.
Hi Diego,
I remembered, there is a relatively simple configuration which allows q-values to be handled. E.g. if there is a single 303 redirect from the vocabulary URI to a second resource, and then content negotiation is performed from the second resource, you can use apache's built-in content negotiation support (via multiviews or type maps). N.B. this configuration *does not* do "conditional redirects", but does content negotiate *after* the first redirect.
The problem with this configuration is that the HTML and RDF files must reside in the same directory on the same server. We didn't like that at the time, because e.g. W3C and dublin core both tend to put the HTML and RDF files in different directories, so you have to do 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: 25 July 2007 11:37
> To: SWD WG
> Subject: Re: [Recipes] ISSUE-58: .htaccess 'accept header'
> ONLY responds to a header which EXACTLY matches
> \"application/rdf+xml\"
>
>
> 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 Monday, 30 July 2007 15:52:35 GMT