rack-contrib addition: Rack::RelativeRedirect

rack-contrib addition: Rack::RelativeRedirect

[Jeremy Evans]

I'm lazy, so here's the commit message (http://github.com/jeremyevans/
rack-contrib/commit/63a61782bb2418f98199403d50480187e8534fde):

    Add Rack::RelativeRedirect, which transforms relative paths in
redirects to absolute URLs

    This allows your web applications to use simple relative paths in
    their redirects if they want, so they don't have to worry about
    the url scheme, server name, or port.  Absolute URLs are not
    modified.  This uses a sensible default based on the environment,
    but gives the user full control by allowing them to specify a
block
    that provides the absolute part of the url (e.g. http://example.org).

    Currently, this only takes affect if the response code is 301-303,
    I'm not sure if other status codes should be considered, but they
    should be easy to add if so.  Also,  this currently only considers
    Locations starting with http:// or https:// as absolute URLs.  If
    other protocol schemes should be considered, those can be added
    later.

    This code will fail if the Location includes the server name part
    but not the protocol scheme (e.g. Location: //example.org/path).
    If those should be allowed, we can do so, but that's also a valid
    relative path, so it's not without its problems.

    This implementation works with both relative and absolute paths.
    If a relative path is given (not starting with a slash), it
    is made relative to the request path.  I'm not sure if this works
    perfectly, though it passes the specs I wrote.

Available in the relative_redirect branch of my fork.

Thanks,
Jeremy

Re: rack-contrib addition: Rack::RelativeRedirect

[Ryan Tomayko]

On Sun, Feb 8, 2009 at 9:45 PM, Jeremy Evans <jeremyevans0@gmail.com> wrote:
>
> I'm lazy, so here's the commit message (http://github.com/jeremyevans/
> rack-contrib/commit/63a61782bb2418f98199403d50480187e8534fde):
>
>    Add Rack::RelativeRedirect, which transforms relative paths in
> redirects to absolute URLs
>
>    This allows your web applications to use simple relative paths in
>    their redirects if they want, so they don't have to worry about
>    the url scheme, server name, or port.  Absolute URLs are not
>    modified.  This uses a sensible default based on the environment,
>    but gives the user full control by allowing them to specify a
> block
>    that provides the absolute part of the url (e.g. http://example.org).
>
>    Currently, this only takes affect if the response code is 301-303,
>    I'm not sure if other status codes should be considered, but they
>    should be easy to add if so.  Also,  this currently only considers
>    Locations starting with http:// or https:// as absolute URLs.  If
>    other protocol schemes should be considered, those can be added
>    later.
>
>    This code will fail if the Location includes the server name part
>    but not the protocol scheme (e.g. Location: //example.org/path).
>    If those should be allowed, we can do so, but that's also a valid
>    relative path, so it's not without its problems.
>
>    This implementation works with both relative and absolute paths.
>    If a relative path is given (not starting with a slash), it
>    is made relative to the request path.  I'm not sure if this works
>    perfectly, though it passes the specs I wrote.
>
> Available in the relative_redirect branch of my fork.

Good stuff. I've merged with a few modifications. These are all minor
nits but worth mentioning for future patches since you seem to be on a
role here :)

* Added a bullet to the README with a summary of the new middleware.
* Keep the commit message summary line under 65 characters (preferably 50).
* Rewrapped RDoc to 80 chars.

Thanks,
Ryan

Re: rack-contrib addition: Rack::RelativeRedirect

[Jeremy Evans]

On Feb 8, 10:01 pm, Ryan Tomayko <r...@tomayko.com> wrote:
> Good stuff. I've merged with a few modifications. These are all minor
> nits but worth mentioning for future patches since you seem to be on a
> role here :)
>
> * Added a bullet to the README with a summary of the new middleware.
> * Keep the commit message summary line under 65 characters (preferably 50).
> * Rewrapped RDoc to 80 chars.

Wow, that was fast, thanks.  I'll keep those things in mind if have
more additions/patches (none planned now, though).

Thanks,
Jeremy