- From: Diego Berrueta <diego.berrueta@fundacionctic.org>
- Date: Wed, 25 Jul 2007 12:36:33 +0200
- To: SWD WG <public-swd-wg@w3.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 UTC