Blank Page - after posting a form in 4.1 final

By shane on 25 Mar 2003 at 01:14 UTC

All,

I've been madly working on building a site from the ground up with Drupal. I've pretty much nailed things down, and gotten everything to behave the way I want it. But, lately, I've noticed a bug with form posting. On occasion, I fill in a form (eg a "Comment" form), then click "preview", then "submit". Sometimes, I get nothing but a blank page back, with only the following HTML source in it:

The URL string is set to:

http://10.0.0.12/node.php?id=8&PHPSESSID=0d9d6122dee3ff365b9fced83fa5b85a

Which is interesting, because I thought that PHP Sessions
weren't used in Drupal. I've noticed if I delete the Ampersand to the end of the Session ID, then resubmit, it'll work fine. Finally URL I actually submit looks like:

http://10.0.0.12/node.php?id=8

I suspect the form posted correctly, and now I'm just viewing the results of that?

I'm running Drupal 4.1.0 final/release code, PHP 4.2.2 on Apache 2.0.40 on a RedHat 8.0 Linux platform. Backend is MySQL 3.23.54.

I've so far only noticed it happening on Mozilla 1.2.1 and Mozilla 1.3. However, I haven't been heavily testing any other browser.

Is there a known issue here, or is this something I can fix? I can't have this sort of behavior with a production site. If there is more detail I can provide, or anything I can do or try to troubleshoot, let me know.

v/r
Shane

P.S. Cookies are set to "Enable All Cookies" in Mozilla.

Comments

FYI - I did search ...

shane commented 25 March 2003 at 01:20

FYI - I did search the site for "blank page" (as one term), but got nothing, so I tried just "blank page" as two separate terms, and got a lot, but nothing immediately relavant and obvious.

v/r
Shane

Possibly theme related

Dries commented 25 March 2003 at 08:00

There has been some "blank page" reports, most of which could be tracked down to incorrect custom themes, broken themes from the contributions repository (which we removed last week), and occasionally, theme Goofy (which we removed from the development branch). Can you reproduce the problem when you use a standard Drupal theme (other than theme Goofy)? For example, disable all themes but theme Marvin, make it the default theme, and see if the problem persists.

If the problem remains, try grabbing the DRUPAL-4-1-0 branch from CVS; it is the 4.1.0 release with some minor fixes. It might have been fixed.

Keep us posted and I'll help you track down the problem.

reproduced under Marvin theme

shane commented 25 March 2003 at 23:44

I was able to successfully reproduce the problem, under Internet Exploder, using Marvin theme. Posting a comment to a form, produced a blank page, with the PHPSESSIONID in the URL. Deleted the extraneous URL string, and all was good. --is there anything I can provide for debugging or additional help?

v/r
Shane

tried under Interlaced theme

shane commented 25 March 2003 at 23:48

I used Interlaced theme for a while. I noticed that under IE, the URL string gets a PHPSESSIONID written into it sometimes during comment posts. However, the page is drawn properly under this theme, and does not present a problem like Marvin or my hacked UnconeD theme.

v/r
Shane

XSilver not broken

shane commented 26 March 2003 at 00:08

XSilver seems to not be broken

reproduced under XTemplate

shane commented 26 March 2003 at 00:08

XTemplate is broken as well

No luck but try this ...

Dries commented 26 March 2003 at 09:07

I tried to reproduce the problem with theme Marvin, yet to no avail. Initially, no session IDs were being added to the URLs nor did I get blank pages. Then, I set the value of session.use_trans_sid to 1 through my .htaccess file which causes the session ID to be added to the URL after hitting the "Post comment"-button. I posted 5 comments as an authenticated user and 5 comments as a anonymous user, yet no blank pages ...

As it stands, I suspect the drupal_goto() function or the use thereof. If you are familiar with PHP, I suggest you frod with that a little. You can find the function in the file includes/common.inc. Here are some suggestions:

drupal_goto(): we should not get behind the calls to header() so you could try to put some debug statements after these to see if they get printed (they should not).
comment_page(): in the comment module, near line 714 is the call to drupal_goto() that causes the page to be reloaded. Try changing that statement by passing it a hard-coded URL and/or by passing it an absolute URL instead of a relative URL.

some notes on your suggestions: what I've done

shane commented 26 March 2003 at 17:59

I tried a couple of different things to try and target where/what's going on. Not much of a PHP hack myself, so this is all blind fumbling.

Passing a hard-coded url via the drupal_goto() function (called in forum.module by the "post comment" action) does the same thing. Whatever page gets reloaded has the problem.

I also changed my local session.use_trans_sid variable in .htaccess to be 0. The only thing this did is not append the PHPSESSIONID string to the URL. Behavior is otherwise, exactly the same. If I manually reload a page (with or without the PHPSESSIONID appended to it) - it'll reload properly.

I (temporarily) modified the drupal_goto() function to simply issue header("Location: $url"); instead of mucking around with the session state info. This didn't do any good either.

...then I simply changed the comment.module call to the drupal_goto() function to directly use the PHP header() call. Same results.

...so I suspect this must be an issue with the version of PHP I'm using (4.2.2)?

I've searched through the PHP bug database for header related problems (930 total bugs!) - there are a number of reports of header() being bad in 4.2.x code - but some mention that 4.2.2 was supposed to have fixed....aparantly not. I'm going to persue an upgrade my PHP and see if that fixes the issue.

v/r
Shane

Keep us posted

Dries commented 26 March 2003 at 19:00

Thanks for the update, shane. Keep us posted because I'm extremely curious to know what the outcome is of such an upgrade.

...sigh...

shane commented 26 March 2003 at 23:23

Well... I just went through many torturous hours of compiling different PHP versions. I had problems with 4.3.0, 4.3.1, 4.2.3 - none of which relates to this problem. Mostly very very odd problems. However, I finally deleted all my old PHP 4.2.2 RPMS - then reinstalled them.

Sadly, it seems that I can't reproduce the problem now. Sadly - because it's the same exact Drupal install, the same version of PHP, same exact php.ini file - just uninstalled and reinstalled.

If I see the problem surface again, I'll let you all know.

double sigh ... sigh ..

shane commented 27 March 2003 at 00:01

I guess I spoke too soon. It behaved for about 20 comment postings, now it's producing blank pages again ... with no provocation on my side. Rather frustrating. I'm sure it's something with the header() call which is going squiffey. Are there any alternatives to calling header()?

v/r
Shane

Me too !

tbarker commented 25 March 2003 at 04:57

I'm getting this as well over at thomasbarker.com.
The articles and blogs go fine even if they preview blank. But my comments system is very dodgy. Does anyone know if this has been fixed in the CVS? I can't find any reference to it in the tracker.