Differences between revisions 15 and 16
Revision 15 as of 2013-06-05 21:41:25
Size: 3484
Comment: official docs link
Revision 16 as of 2013-06-19 15:44:53
Size: 3223
Editor: RobertNewson
Comment: remove dead link
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

[[http://blog.couchbase.com/what%E2%80%99s-new-apache-couchdb-011-%E2%80%94-part-one-nice-urls-rewrite-rules-and-virtual-hosts|This post]] has examples and shows how to combine Rewriting with [[Virtual_Hosts|Virtual hosts]] to generate nice URLs in CouchDB.

We have a new wiki. The migration is not 100% complete. You can help out by moving pages across. This wiki will exist for as long as there are pages left.

The official documentation has moved to http://docs.couchdb.org — The transition is not 100% complete, but http://docs.couchdb.org should be seen as having the latest info. In some cases, the wiki still has some more or older info on certain topics inside CouchDB.

You need to be added to the ContributorsGroup to edit the wiki. But don't worry! Just email any Mailing List or grab us on IRC and let us know your user name.

This is an overview of http rewrite handler.

See also the official documentation for this topic.

The HTTP Rewrite Handler

The http rewrite handler. All rewriting is done from /dbname/_design/ddocname/_rewrite by default.

each rules should be in rewrites member of the design doc. Ex of a complete rule :

{
    ....
    "rewrites": [
    {
        "from": "",
        "to": "index.html",
        "method": "GET",
        "query": {}
    }
    ]
}
  • from: is the path rule used to bind current uri to the rule. It use pattern matching for that.

  • to: rule to rewrite an url. It can contain variables depending on binding variables discovered during pattern matching and query args (url args and from the query member.)

  • method: method to bind the request method to the rule. by default "*"

  • query: query args you want to define they can contain dynamic variable by binding the key to the bindings

to and from are path with patterns. pattern can be string starting with ":" or "*". ex: /somepath/:var/*

This path is converted in erlang list by splitting "/". Each var are converted in atom. "*" is converted to '*' atom. The pattern matching is done by splitting "/" in request url in a list of token. A string pattern will match equal token. The star atom ('*' in single quotes) will match any number of tokens, but may only be present as the last pathtern in a pathspec. If all tokens are matched and all pathterms are used, then the pathspec matches. It works like webmachine. Each identified token will be reused in to rule and in query

The pattern matching is done by first matching the request method to a rule. by default all methods match a rule. (method is equal to "*" by default). Then It will try to match the path to one rule. If no rule match, then a 404 error is displayed.

Once a rule is found we rewrite the request url using the "to" and "query" members. The identified token are matched to the rule and will replace var. if '*' is found in the rule it will contain the remaining part if it exists.

Examples:

Rule

Url

Rewrite to

Tokens

{"from": "/a/b", "to": "/some/"}

/a/b?k=v

/some/k=v

k = v

{"from": "/a/b", "to": "/some/:var"}

/a/b

/some/b?var=b

var = b

{"from": "/a", "to": "/some/*"}

/a

/some

{"from": "/a/*", "to": "/some/*}

/a/b/c

/some/b/c

{"from": "/a", "to": "/some/*"}

/a

/some

{"from": "/a/:foo/*","to": "/some/:foo/*

/a/b/c

/some/b/c?foo=b

foo = b

{"from": "/a/:foo", "to": "/some", "query": { "k": ":foo" }}

/a/b

/some/?k=b&foo=b

foo =:= b

{"from": "/a", "to": "/some/:foo" }

/a?foo=b

/some/b&foo=b

foo = b

Paths are relative to the design doc, so "/" mean the design doc too and "../" mean the path above the design doc and so on.

Rewriting_urls (last edited 2013-06-19 15:44:53 by RobertNewson)