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

El lun, 30-07-2007 a las 16:52 +0100, Miles, AJ (Alistair) escribió:
> 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.

That sounds interesting, I'll give it a try as soon as possible.

In the meanwhile, I've tried a simpler approach that partially solves a
couple of test cases. Unfortunately it doesn't tackle the root of the
problem (the negotiation based on the q-values), so it still fails in
the general case.

As I said in a previous message, there is a trick to make cases (e) and
(f) pass at the same time. Just a quick remainder, for your convenience:

  Case e) Accept: application/rdf+xml,text/html
  Case f) Accept: text/html,application/rdf+xml

The trick is to add another condition to the rewrite rules. For
instance, Recipe 3 would read:

# Rewrite rule to serve HTML content from the vocabulary URI if
requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|
application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

# Rewrite rule to serve RDF/XML content from the vocabulary URI if
requested
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

The only change I've made is the new RewriteCond after the first
comment. In this way, we avoid the first rule matching when
"application/rdf+xml" precedes "text/html". The first tests show that
this change is enough to make test cases (e) and (f) succeed
simultaneously. Note that there's no need to update the second rule.

I'm sure that the same trick can be also implemented with a more complex
regular expression, probably by means of the "negative lookbehind"
operator. I haven't managed to write such expression, however.

The most challenging test cases, namely (c) and (d), are still unsolved.

Best regards,

--
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, 6 August 2007 18:25:23 UTC