Bug: Bug in redirecting a Url from a plugin in Dakar

The sequence

my $url = &TWiki::Func::getViewUrl( $web, $topic );
&TWiki::Func::redirectCgiQuery( $query, $url );

should redirect to the view topic. However, when used in a plugin, this call ends up with the following two problems:

• when called from a viewauth topic it keeps showing the viewauth page and is not redirected to view
• it inserts Status: 302 Moved Location: ... at the very beginning of the %TEXT%
• it does not properly pass this topic into the plugins

I am not sure what is going on. But the consequence is that, for example, EditTablePlugin does not work, and similar for any other plugin which uses this sequence.

Test case

Create a table using EditTablePlugin, edit, and save. You will find that after the save the topic is still in viewauth, and the %EDITTABLE...% tag is now visible in cleartext (rather than handled by the plugin). Note that the topic has been saved, which can be seen by editing the Url to use view and refreshing the screen; then the plugin handling works also...

Environment

TWiki version:	Dakar
TWiki plugins:	DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:
Web server:
Perl version:
Client OS:
Web Browser:

-- ThomasWeigert - 09 May 2005

Impact and Available Solutions

All plugins using above pattern will fail.

Follow up

Fix record

Discussion

Can somebody please try this on their machine? I don't know what is happening here. According to my traces, just before the

$query->redirect($url);

the url is blablabla/bin/view/Test/WebPreferences. However, the redirect stays at blablabla/bin/viewauth/Test/WebPreferernces, and prints as the first line in %TEXT%

Status: 302 Moved Location: blablabla/bin/view/Test/WebPreferences 

Note that this works just fine on Cairo on my machine...

-- ThomasWeigert - 09 May 2005

Somehow it appears to me, but I don't understand why, that there is a problem redirecting out of a plugin handler call.

This is easily demonstrated... write a plugin handler that just redirects... the same behavior results....

-- ThomasWeigert - 09 May 2005

I wonder if this is something to do with view having already printed the HTTP header before the redirect is sent from the plugin? Try stopping View.pm from printing anything until after the plugin handler should have triggered.

-- CrawfordCurrie - 09 May 2005

Bingo...

You are 100% right. Once the header is written out, we cannot redirect any longer.

We either need to come up with a different strategy of redirecting, or write the whole session at once.

There are a number of plugins right now that will no longer work.

If I save the output until all the plugins have done their work and only write thereafter, then this problem does not occur...

-- ThomasWeigert - 09 May 2005

As Crawford diagnosed, the problem was caused by the topic being written in stages to speed up rendering. While this sounded like a good idea, in fact once the header was written, one cannot redirect any longer to another page. This will break all plugins and applications which manipulate the viewed topic and eventually redirect to another page (most prominent example: EditTablePlugin).

Reverted to original behavior of writing the topic at once. The framework for writing in stages is left in the code, but the page is collected in a variable and written at once. In SVN 4280.

-- ThomasWeigert - 10 May 2005

Bummer. By the nature of the way pages are compiled there is no way around this. The work that tells you if you need to redirect is the heavy part of the page generation process (basically it's the topic access controls checks). The idea was to generate some pretty pictures for the user to look at while that generation was going on.

Oh well, it was a good theory.

-- CrawfordCurrie - 10 May 2005