On Dec 13, 2005, at 5:20 AM, mario ruggier wrote:

> Just to clarify... are there ever any situations where from any
> given page you want to "set" something (that involves attaching
> some info to the response headers -- e.g. sign_out does not fit
> this case as it does everything only server-side) and come back to
> the page, taking the new "setting" into account ?
> In my case I am setting a preferred language cookie...

Understood.  I was just saying that we don't do that in our
applications.

> What would the arguments be against a init_response=True param to
> pub.redirect()

I try to resist adding keyword arguments where the value of the keyword
is, from the caller's point of view, a constant.  The "permanent"
keyword
that is already in redirect, is an example of what I try to resist:
the caller
would always know in advance if this is a permanent or temporary
redirect.  I'd rather just have a separate redirect_permanent() method
because I think this makes it easier to understand the behavior of
the method.  Adding an init_response keyword makes this situation
more extreme.

I think your use-case is common enough to justify some support from the
Publisher.  I'm trying to figure out the best way to do that.
Is it correct that it is always set-cookie header(s) that one
would want to preserve?
Should we just delete the init_response() call?