[99s-extend] Rewriting URLs

Paul Dickson pdtwonotes at gmail.com
Mon Jan 26 22:54:09 CET 2015


On Mon, 2015-01-26 at 11:26 +0100, Loïc Hoguin wrote:
> You have to change path_info too if your middleware is after the router.
> 
I have added that.  My cowboy:start_http parameters include this:
    {middlewares, [cowboy_router, bz_libmap, cowboy_handler]}
which I think means bz_libmap will get called on *every* request.  This
seems to work.  Among the dispatch rules is this line:
    {"/music/[...]", cowboy_static, {dir, "", ""}},
so any request starting with "/music/ will do a standard file fetch.
But due to the middlewares setup, bz_libmap will get a chance to
look at it first.

bz_libmap checks the path to see if it starts with "/music/", and if
not, it just returns {ok,Req,Env} and lets processing proceed normally.
This works, and other dispatch rules take care of it, usually fetching
files from priv_dir.

But if bz_libmap sees "/music/" at the start of the URL it transforms
the URL into something else, an absolute filename typically of an mp3
file.  This is what I want cowboy_static to process.  Hopefully, this
does not run through the dispatch rules again.

bz_libmap computes a new path and a new path_info and sets them with a
cowboy_req:set call.  I am not sure what path_info should look like at
this point, because the path is no longer covered by any of the dispatch
rules.  I do not want it to be, as that would allow a browser to fetch
any file in the file system, unchecked.

But what happens is any attempts to fetch /music/Anything result in a
status 400 error.

The other approach I was considering was to make my own handler, based
on cowboy_static, that does the URL/File transformation internally.  But
even that might not be right, since it eventually upgrades to
cowboy_rest and there is more processing after that.  This approach
seems inelegant.

The actual only call to file:open I found in all of cowboy is in
cowboy_spdy.





More information about the Extend mailing list