There is new code in
in comparison to Cairo: When parameters are passed through, if the request_method was GET, then all parameters can be passed in the URL. If the request_method was POST then it caches the form data and passes over a cache reference in the redirect GET.
This defeats the purpose of a pass through for POST methods. There may be some logic behind this, but I don't understand it. With the cache manipulation, neither the oops dialogs nor the going beyond oops dialogs works.
I found out later that this change was done in response to Item2295 with the intention to pass the parameters across redirects. But it does not work right.
A fix is necessary to utilize the changes made to the redirection mechanism in TWiki4, and also to address issues such as the critical Bugs:Item2614.
Setting this to requirement, as the Oops dialog for lease conflict does not work (select the "Try" button to see the problem). -- TW
Agreed, it doesn't work, but not for the reasons you think.
Passthrough works so that a POST query which is redirected has it's parameters cached, so that when the redirection page comes up the original query parameters are restored. This is required because a redirect uses a GET, and throws away the original POST parameters.
In the case of the lease conflict page, when a lease conflict occurs, a redirection to an oops page happens. This redirection is set to be parameter preserving (keep
> 1) which causes it to cache the post parameters. At the same time, new values for the same parameters are written (by =getOopsUrl
) into the redirection URL. When this URL is loaded, the cache is loaded and overwrites the parameter values in the redirection URL.
This is trivially fixed by removing the
parameter from the Oops exception.
If you encounter another example of this (parameters appearing to get stuck on an oops redirection) then the first thing to check is if there's a
on the oops redirection, and if there is, commenting it out.
Closing, because the bug doesn't affect any released versions.
Opening again, because it is a requirement that the oops dialog on lease conflict works. Just because it is not broken in a released version does not mean we should break it in the next release.
I'll check on your suggestion with the "keep". -- TW
As far as I can tell, this behavior has nothing to do with the "keep" (I cannot even see how the keep could come into play). What I observe is the following:
- When an oops url is constructed, a set of parameters (
param1, etc.) are set up
- Then a redirect is called on
- If the redirect does not use the
$passthrough set to true, all the original parameters of the query are dropped.
$passthrough is used, and the request was a POST, then supposedly a cache is constructed from the parameters and a url parameter indicating the redirect cache is prefixed to the query, e.g.,
- Else, the query parameters are copied into the url and sent on together with the new parameters.
- The new page is written.
In the case of a redirect using an oops url
- behavior (2.1) clearly does not work, as we do not get the new parameters along, and the oops has nothing to continue on to.
- behavior (2.2) does not work either (at least not on my machine). The cache parameter blocks all the other url parameters from being seen, and thus, the page cannot be properly constructed, as no template is given.
- behavior (2.3) works correctly, but is not invoked.
This is clearly broken. There is something wrong about the cache mechanism that prevents both the rest of the parameters being seen and the cache from being read (actually, I don't see any cache being even written). I don't even understand why it is needed, as when I comment out this code, everything seems to work just fine.
Please explain why this is needed, and if so, please fix the cache mechanism. -- TW
Again, the cache mechanism is not broken, it is the oops mechanism that is broken. It was a nasty hack to try and work round the lack of a cache mechanism, and is now biting back. The scenario is as follows.
- Browser invokes an edit URL with a set of parameters. Call this URL + parameters the original request.
- An oops exception is raised, and a redirect request formulated.
- A redirect is a GET, so parameters can only be passed on in the URL. This means that either the parameters must be encoded in the URL string, or cached, and a cache id placed in the URL instead.
keep is 1, then it tries to do both - the oops code encodes the oops parameters in the URL, but then the
redirect code adds a cache reference for the saved original request parameters.
- When the redirect is executed, the query parameters are the oops parameters from step 2 + a cache reference
- The cache is loaded, wiping out the parameters in the url
My fix was wrong. The solution to this is to reinstate the
instruction on the exception, but get the oops code to add the oops parameters to the original request
, so that when it is cached, those parameters get cached as well. The redirect will then not have a parameter string
, except for the cache id.
Analysed, so changing state to Actioning.
Thanks. The cache is currently not effective upon redirect. It works when manually creating a cache and loading the cache in the URL manually. Don't understand what needs to be done to load the cache upon redirect.
- Will this lead to a slowdown due to the writing and reading of these parameters?
- I doubt it. The cache is extremely simple and small. CC
- Further, this redirect will not keep parameters across machines, unless the same location is mounted on all (probably not a big issue).
- Should this simple problem really be solved in such elaborate way? Do we really have scenarios other than the login example, where we pass huge amount of data across a redirect?
- "Huge" is a relative term. Some servers limit GET requests to 1024 bytes, which isn't all that "huge". Oops is another case, and it's easy to envisage other intermediate pages you may want to visit. I think it's essential to have a generic solution to this problem, rather than trying to hack each individual case (as was done previously). The solution I coded really isn't all that elaborate, except where it intersects with the aforementioned hacks. But if you can code a better alternative, please go ahead! CC
OK. Will you be fixing this or am I? -- TW
I'll do it, I know what has to be done.
Fixed. Closing, because it was a bug in unreleased code.