Re: mitigating cost of 303

On Wed, 2012-01-04 at 08:59 -0500, David Wood wrote:
> On Jan 3, 2012, at 20:59, Sandro Hawke wrote:
> 
> > On Thu, 2011-12-22 at 13:37 +0000, Steve Harris wrote:
> >> FWIW I agree with him that a 303 is a very high cost to pay.
> > 
> > In confusion or in extra round-trips?
> > 
> > I have an engineering solution to the latter, which is that hosts be
> > allowed to expose (via a .well-known URI) some of the rewrite rules they
> > use.   Then, if I (as a client) find myself getting lots of redirects
> > from a host, I could look for this redirect-info file, and if it
> > appears, I can do the redirects in the client, without talking to the
> > server.   
> > 
> > This wouldn't be only for RDF, but I'd expect only people doing 303 to
> > care enough to set this up on their hosts or have their clients look for
> > it.
> > 
> > The hardest engineering part, I think, is figuring out how to encode the
> > rewrite rules.  
> 
> Weren't you the editor of RIF in RDF [1]?

*laugh*   

I was thinking something more like json:

        [ { verb: "GET", from: "/r/(.*)", to: "/page/$1", code: 303 },
          { verb: "GET", from: "(/data/.*/[^.])", to: "$1.rdf", code:
        303 } ]
        
The second rule assumes everything under /data has a form with no suffix
(no dots in the last segment) that redirects to the same name with .rdf
appended.

Doing it in RIF would certainly be an interesting exercise.  (I spent a
few minutes sketching it now.)  I doubt it would appeal to the target
audience of http server and client library implementers!

    -- Sandro
 
> Regards,
> Dave
> 
> [1] http://www.w3.org/2005/rules/wiki/RIF_In_RDF
> 
> 
> > Each server has its own fancy way of doing it.  Like
> > which version of regexps, and how to extract from the pattern space;
> > lots of solutions, but we'd need to pick one.   And, tool wise, one
> > would eventually like the web servers to automatically serve this file
> > based on the rewrite rules they are actually using.   :-)
> > 
> >   -- Sandro
> > 
> > 
> > 
> 
>

Received on Wednesday, 4 January 2012 14:40:58 UTC