> or more generally, how does one supply POST data to an HTTPRedirect. > That
> would allow both modes of operation. (and eliminate cookie > dependence too,
> I think). I think that's a fairly ugly hack, and in combination with how
> HTTP redirects work, impossible at worst, impractical at best. HTTP
> redirects send the "Location: ..." header to the user's browser, and the
> user's browser requests the targeted page. Thus passing the data through
> POST via redirect, AND setting the cookie is simple overkill. Also, POST
> data tends to confuse user's browsers (and thus users) when the history
> buttons are used. I'm attempting to get my users away from unnessicary
> "re-send POST data?" messages, and so far redirects are working well.
> Instead, having the turbogears.flash() function define a KID global
> (turbogearsflash) when called AND when the cookie is found would be the best
> option. Having the function call override the cookie is also logical. This
> solution would keep existing support as-is (no new variables or methods to
> call), and saves redundant bandwidth. I was also bitten by the every-other
> problem with Cookies, and now can't seem to get the cookie to go away! Any
> way to force deletion of this cookie?
