Dieter Maurer replied:
Spicklemire, Jerry writes:
When I call "REQUEST.redirect(other_url)", the REQUEST isn't destroyed, in fact all the parameters are retained, right down to the original method, so that a "get" method passes parameters appended to the URL, and a "post" method includes all the original REQUEST parameters in the header.
The HTTP/1.1 specification is unfortunately very vague with respect to what should be done with the request parameters. Thus, browsers have some freedom what they do about them.
Oh joy, I haven't even gotten around to testing cross-browser yet! This could very well be an MS Expoder problem. I'll try NS today.
I am unsure what behaviour I would favour:
If I have a GET method, I would usually not like the browser to append the old request parameters. For, if I would like them available, I can easily add the QUERY_STRING myself.
However, if I have a POST method, I cannot provide the request body in the redirect. It would be natural when the browser would send the original request body just to the new location.
I think, the second behaviour is more in line with the notion of redirection: send the same request to a different URL. However, my browser (Netscape 4) implements the first behaviour.
The bottom line for me is how to get Zope to do what is needed. It's very possible that I'm once again blurring the line between client side and server side behavior. Symptoms of late stage Javascript burnout. In simplest terms, how can I leverage Zope to point from one page to another and make certain that the troublesome parameters are no longer around to cause problems?
Why are you unhappy about the parameters. Usually, they do not hurt.
My guess is that it's the Acrobat plug-in isn't happy about them, so it can't just display the .PDF file, instead it generates an error message. However, all I have to do is to hit <shift> <refresh> and the .PDF displays normally. Yet another mystery . . . Thanks, Jerry S.
Spicklemire, Jerry writes:
In simplest terms, how can I leverage Zope to point from one page to another and make certain that the troublesome parameters are no longer around to cause problems? Difficult question.
It is not Zope that puts them there. If they are really around, then the browser did this. Maybe one of the other "Redirect" status codes defined by HTTP/1.1 can help you. But beware, HTTP/1.0 clients probably will not understand them.
Why are you unhappy about the parameters. Usually, they do not hurt.
My guess is that it's the Acrobat plug-in isn't happy about them, so it can't just display the .PDF file, instead it generates an error message. However, all I have to do is to hit Very strange indeed.
My current understanding suggests that the Acrobat plug-in should not see them. I would expect, the browser makes the redirection, fetches the HTTP response, recognizes from the "Content-Type" that it is something handled by a plugin and transfers it to this plugin. But I am not a plugin expert... By the way, you do not need a redirect to deliver a PDF file. If you are *VERY* careful about whitespace, you can deliver it with a DTML object: <dtml-var "fileobject.index_html(REQUEST,RESPONSE)"> However, I fear, if parameters are really your problem, then it will remain, as there are parameters that you want to get rid off. Dieter Dieter
participants (2)
-
Dieter Maurer -
Spicklemire, Jerry