[hunchentoot-devel] [patch] redirect* (allows to set status code)

Hi, attached is a patch which adds and exports a new function REDIRECT* (including changes to documentation). It is like REDIRECT, except that it has a keyword argument CODE instead of PERMANENTLY. This is to allow returning 303 (See Other) while staying backwards compatible. The alternative would be to add the CODE keyword argument to REDIRECT, and figure out the semantics when both :code and :permanently are given. I can prepare a patch for that, too, if this is preferred (and somebody states the proposed behavior as docstring ;)). Cheers, Michael

On Tue, 11 Mar 2008 12:15:23 +0100, Michael Weber <michaelw+tbnl@foldr.org> wrote:
attached is a patch which adds and exports a new function REDIRECT* (including changes to documentation). It is like REDIRECT, except that it has a keyword argument CODE instead of PERMANENTLY. This is to allow returning 303 (See Other) while staying backwards compatible.
The alternative would be to add the CODE keyword argument to REDIRECT, and figure out the semantics when both :code and :permanently are given. I can prepare a patch for that, too, if this is preferred (and somebody states the proposed behavior as docstring ;)).
Thanks for the patch. I would personally prefer to have only one function for this task at the risk of not being backwards compatible, i.e. I'd simply remove :PERMANENTLY. Maybe we can have a quick poll: If anybody with lots of production Hunchentoot applications is absolutely relying on the :PERMANENTLY keyword, please speak up now... :) Cheers, Edi.

On Mar 11, 2008, at 12:32 , Edi Weitz wrote:
Thanks for the patch. I would personally prefer to have only one function for this task at the risk of not being backwards compatible, i.e. I'd simply remove :PERMANENTLY. Maybe we can have a quick poll:
Be my guest :) New patch attached.
If anybody with lots of production Hunchentoot applications is absolutely relying on the :PERMANENTLY keyword, please speak up now... :)
For those applications it's anyway easy enough to have a local version of REDIRECT which wraps HUNCHENTOOT:REDIRECT. Cheers, Michael

On Tue, Mar 11, 2008 at 12:32:37PM +0100, Edi Weitz wrote:
Thanks for the patch. I would personally prefer to have only one function for this task at the risk of not being backwards compatible, i.e. I'd simply remove :PERMANENTLY. Maybe we can have a quick poll:
If anybody with lots of production Hunchentoot applications is absolutely relying on the :PERMANENTLY keyword, please speak up now... :)
I use :permanently in a lot of places and would be a little annoyed if it disappeared. Zach

On Tue, Mar 11, 2008 at 02:02:07PM +0100, Edi Weitz wrote:
On Tue, 11 Mar 2008 08:44:34 -0400, Zach Beane <xach@xach.com> wrote:
I use :permanently in a lot of places and would be a little annoyed if it disappeared.
I thought you were still using TBNL...
I upgraded one of my two sites using TBNL to hunchentoot, and I was very pleasantly surprised by how little I had to change. When I (eventually) upgrade the second site, this change would make me less pleasantly surprised. :) Zach

Why not support both STATUS-CODE and PERMANENTLY and make it an error to specify both? -Hans 2008/3/11, Zach Beane <xach@xach.com>:
On Tue, Mar 11, 2008 at 02:02:07PM +0100, Edi Weitz wrote:
On Tue, 11 Mar 2008 08:44:34 -0400, Zach Beane <xach@xach.com> wrote:
I use :permanently in a lot of places and would be a little annoyed if it disappeared.
I thought you were still using TBNL...
I upgraded one of my two sites using TBNL to hunchentoot, and I was very pleasantly surprised by how little I had to change. When I (eventually) upgrade the second site, this change would make me less pleasantly surprised. :)
Zach
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

On Tue, 11 Mar 2008 09:07:59 -0400, "Hans Hübner" <hans@huebner.org> wrote:
Why not support both STATUS-CODE and PERMANENTLY and make it an error to specify both?
That's of course possible, but it's a bit ugly, isn't it? Reminds of the story how they didn't change the crufty syntax of Make back then because they already had half a dozen active users. At least, discussions like this one explain why Common Lisp isn't as lean and elegant as some people would like it to be. If Zach is the only one complaining, I still think it is better to burn our bridges behind us. (Sorry, Zach...)
participants (4)
-
Edi Weitz
-
Hans Hübner
-
Michael Weber
-
Zach Beane