On Dec 13, 2005, at 1:22 PM, David Binger wrote:
> On Dec 13, 2005, at 5:20 AM, mario ruggier wrote:
>
>> 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 agree with the resistance to parameter proliferation. But
function/method proliferation is a similar problem, or worse if you
start getting into combinations of possibilities... What would win it
for me is how easy can I remember what's available, and which reads
clearer. In the case of permanent, as it seems to be used in very clear
context, it seems good to have a redirect_permanent().

> 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?

My feeling is that all other http headers will always be set during
normal response processing, i.e. not during a redirect.... on the other
hand, it does seem reasonable to do the systematic defensive call of
init_response() on redirects, as you just do not want to worry about
potential problems from having things set on the response prior to the
redirect, that could then cause conflicts. Is there such a potential
problem? Anyway, what was the reasoning for re-initialising the
response on redirects in qp (differs from quixote) ?

m.