Re: mitigating cost of 303

On 04/01/12 01: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?

IMO, both.

It's also difficult to set up, especially if you don't have full control 
of the HTTP server.

> 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.

Interesting possibility although making the client more complicated has 
its downsides.

> 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 original motivation for 303 was for a POST to redirect to GETtable 
content after a form action.  Certainly don't want the client bypassing 
the redirection there!

> The hardest engineering part, I think, is figuring out how to encode the
> rewrite rules.  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.   :-)

For all approaches to IR/NIR, what happens about PUT related to the NIR 
that creates the NIR?

For 303-ization, I can see how it might work by doing a GET (HEAD?) 
discovering the redirect and doing the PUT to that.  A bit complicated 
and assumes that the 404 isn't generated by the first part.

For #-URIs, it seems to need understanding of the whole non-# doc.

 Andy

Received on Wednesday, 4 January 2012 10:19:04 UTC