Re: Rules.CSV format as alternative to htaccess

Stian and all, hello.

On 3 Mar 2016, at 11:09, Stian Soiland-Reyes wrote:

> One thing that comes up when I'm looking at the redirections
> is that there's often the with and without slash variants.. e.g.
> and -- it would be
> good if these could be represented within /pav/rules.csv  rather than
> also have a line in /rules.csv  -- perhaps the special values should
> be empty string for "folder" and "." for "folder/".

That could be represented by a magic value in the "src" column -- say 
"<" or "<>" (which can't appear in a URI path segment).  Presuming that 
the implementation would not parse each rules.csv file dynamically, but 
would ingest them in a preprocessing step, the fact that this applies to 
the 'parent' path need not be a problem.

> As for the existing htaccess rules, I think any non-slash
> folder usage now is indirect through Apache's own directory matching,
> e.g. works as it should by a 301 Moved
> Permanently to which then does 302 Found to
> its final destination.

These and others could potentially be handled by a couple of lines which 
are implicitly appended to each rules.csv file.  If the logic is that 
the first input URIs are handled by the first row in rules.csv which has 
a match in column 1, then these can be overridden easily, but still 
provide consistent behaviour.

The (usual apache) adding-slash behaviour would be


and error behaviour would be the catch-all


It might also be worth specifying that the beginning and end of column 1 
are implicitly anchored with "^...$', where the beginning matches the 
beginning of the part of the URI path component which starts at the 
current path component.  Anchoring both ends would be useful since (a) 
it would probably be good practice to anchor patterns explicitly in any 
case, and (b) it fits in with the most natural/naive reading of the list 
which would have the first column match on path elements (ie, principle 
of least surprise).

Thus adapting your example, we might have


Since 302 Found would be the most typical status code for this service, 
perhaps that could be the default if the "statuscode" column is empty.

If this was in a directory "foo" (or, more abstractly, if this were 
being interpreted in a 'context' 'foo'), then we'd have mappings

.../foo ->
.../foo/ ->
.../foo/sub/folders/allowed ->
.../foo/sub/folders/allowed/bar ->
.../foo/blog/wibble/ ->
.../foo/blog/wibble/woot/ ->
.../foo/blog/wibble/woot ->
.../foo/myblog/stuff -> (and not

All the best,


Norman Gray  :
SUPA School of Physics and Astronomy, University of Glasgow, UK

Received on Thursday, 3 March 2016 13:01:13 UTC