Andreas Kostyrka wrote:
Am Fre, 2002-09-27 um 20.58 schrieb Craeg K Strong:
Thanks for the advice!
Unfortunately, I don't know how to do what you suggest.
I believe that a redirect always causes a GET, rather than a POST, no?
Also, hidden form fields are filled in on the original request, but the redirect flushes the request. All of my fields are gone! :-(
Perhaps I could do something really nasty and override the Python method in urllib2 that handles HTTP redirects?
What to hell does urllib2 have to do with Zope?
Sorry for the non-sequitur.. I do not really know if Zope uses the urllib2 machinery or not. Somewhere, however, there must be some code that catches raise 'Redirect', myurl and does the appropriate thing (creates a new request, etc.). My "find-grep" caught class HTTPRedirectHandler(BaseHandler): (line 427 of urllib2.py) But I have not looked into it enough to understand whether it is what I am guessing it is, and-- even if so-- whether Zope uses it or not. in any event, there are other, better solutions on the table, so at this point it is no longer important...
Today, that code creates a new REQUEST object, throwing away the old request. I could cause it to insert some value that I would then test for, to distinguish the two cases.
REQUEST.redirect sends a status code to the browser which then requests the new URL by itself, ...
That would be the king of all hacks, but it might work :-}
Probably not. The only thing you can do with redirect is to urlencode your parameters, ...
You're probably right. The browser is getting back a status code in the HTTP header that makes it generate a new request. The question I had was: would there be a way to stuff something in the HTTP header that the browser would somehow copy over to the new HTTP header it sends back in response to the redirect status code...? After all, it *does* copy the URL to which it is being redirected, along with all of its query parameters, etc.... A thorough re-reading of the HTTP spec would probably give me an answer... --Craeg
Andreas