Robert Sanderson
unread,Jul 10, 2008, 5:15:27 PM7/10/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to oai...@googlegroups.com
So, I came to implement the redirection from aggregation to resource map today. Easy... or maybe not.
First problem: mod_python makes it very easy to redirect to other resources:
utils.redirect(req, uri_r)
However it will only do MOVED_PERMANENTLY (301) and MOVED_TEMPORARILY (302).
Okay, so look at the redirect() code and change it to do SEE_OTHER (303).
Being:
req.err_headers_out["Location"] = uri_r
req.status = apache.HTTP_SEE_OTHER
req.write(uri_r) # probably unnecessary
raise apache.SERVER_RETURN, apache.DONE
Okay, so there's our 303 redirect, but only to the default resource map (being Atom)... but at some expense, and for what real gain compared to 301 or 302? (Yes I know, the semantics are different, but ... geez!)
Now, the python foresite library serialises to atom, rdf/xml, pretty rdf/xml, n3, ntriples, turtle and rdfa (shameless plug!) so I wanted to do content negotiation or somehow else redirect to different serialisations.
Urgh! Went to the ORE document... which seems overly wordy (sorry Simeon!) for what content it does give, and jumps out too quickly to point at the apache documentation and the linked data tutorial. The apache documentation and RFC is pretty opaque, and the linked data tutorial (other than the link in the page currently being broken) is pretty hard to see what's the aggregation, and what're the resource maps. And parsing the Accept header looks like it's seriously not going to be fun.
With my developer hat on, I'd like to see something with traces of headers and a step by step explanation about how to process the requests properly. Also a script to run (or web service to invoke) to check that it's done correctly. Ditto with the proxies.
-- Rob