incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Berjon <ro...@berjon.com>
Subject Re: Rewrite inside of a path segment
Date Thu, 25 Oct 2012 16:29:39 GMT
Hi Nathan,

On 19/09/2012 22:24 , Nathan Vander Wilt wrote:
> On Sep 18, 2012, at 1:16 AM, Robin Berjon wrote:
>> The problem is that I need a rewrite that invariably accepts
>> parameters that don't fall at the / boundary. Typically:
>>
>> { from:   "/blog/*" ,   to:     "../../blog.*" ,   method:
>> "DELETE" }
>>
>> And that doesn't work. It just invariably encodes the * or :id, or
>> whatnot. Have I missed something? I of course could simply expose
>> another ID for DELETE or ugly IDs everywhere, but that completely
>> defeats the point of having rewrites in the first place.
>
> You have not missed anything. The problem is that you're wanting a
> rewrite doesn't fall on / boundaries, and the simplistic rewrite
> handler does not support this. I wish that rewrites were implemented
> in JavaScript instead of this one-off metalanguage, but my dreams
> aren't much practical value to you right now ;-)

As a matter of fact, they are :)

It took me a little while to get back to you because I liked your idea 
of having the rewrite work from JS. So I foolishly picked up an Erlang 
tutorial and went on to implement it. You can find the pull request at:

     https://github.com/apache/couchdb/pull/38

Here's a quick description of how it works:

"""
Alternatively, the rewriting can be performed by a function. It is 
specified as follows:

  {
      ....
      "rewrites": "function (req, path) {
          // process the request, and return the rewrite
      }"
  }

The function is called with the request object and a path string. The 
latter contains whatever path is left after removing everything up to 
_rewrite/.

Which rewrite takes place depends on what the function returns, which 
can be one of three things:

   - false, or a falsy value: indicates that the rewrite could not be
     performed. This translates to a 500 error.
   - "a/path": causes the rewrite to that path to take place, with the
     original method being kept.
   - { path: "a/path", method: "FOO" }: rewrites to that path and changes
     the method to the one provided.

Rewrite functions are meant to be devoid of side-effects and one should 
write under the assumption that they are being cached.
"""

There's a bit more information given in the pull request, and in the tests.

I've only given it a cursory run yet but so far it works pretty well. 
I'd appreciate comments, screams, jokes, etc.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Mime
View raw message