Closed Bug 226251 Opened 22 years ago Closed 21 years ago

internal error when server push is enabled

Categories

(Bugzilla :: Query/Bug List, defect)

2.17.6
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: sreindl, Assigned: sreindl)

Details

Attachments

(2 files, 2 obsolete files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.4.1) Gecko/20031114 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.4.1) Gecko/20031114 Since using rv 1.4.1 of Mozilla server push is providing an internal error in 8 out of ten refresh screen commands in buglist.cgi Reproducible: Sometimes Steps to Reproduce: 1. Use the 'My Bugs' button 2. either it happens immediately or press refresh button some times 3. Actual Results: I get an internal error Expected Results: 1. The same page should appear all the time 2. The value of serverpush should be part of preferences (either user or global) output from error_log: [Wed Nov 19 21:43:25 2003] [error] [client 80.132.202.166] [Wed Nov 19 21:43:24 2003] buglist.cgi: Use of uninitialized value in string eq at /var/www/bugzilla/buglist.cgi line 97.
Version: unspecified → 2.17.6
*** This bug has been marked as a duplicate of 226249 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Well, this is only only half of the problem. Even after fixing this (I was just on the was to prepare a patch and to include this in the issue), I get the following now [Wed Nov 19 22:17:17 2003] [error] [client 80.132.202.166] malformed header from script. Bad header=HTTP/1.1 200 OK: buglist.cgi This isn't really helpful
turn off mod_perl. Bugzilla doesn't work with it yet.
I disabled mod_perl some days ago ... :-(
actually, we override CGI::multipart_init() in order to prevent this exact situation... has anything happened to that override by any chance? In Bugzilla::CGI.pm: # CGI.pm makes this nph, but apache doesn't like that sub multipart_init { my $self = shift; unshift(@_, '-nph' => undef); return $self->SUPER::multipart_init(@_); }
not in my installation, btw should we reopen this issue
why don't we discuss this on the mailing list to see if we can get help tracking this down. For lack of ability to reproduce it I'm suspecting some sort of config issue...
I had this problem too on my installation.. I turned off server push and it resolved the problem.. redhat 9, perl 5.8.. If I can help narrow down the problem, don't hesitate...
ok, so the main problem here isn't a duplicate.... but I'm not convinced it's a bug yet. :) What version of CGI are you using? (the Perl module) More than likely it's a problem with CGI rather than Bugzilla, since this is known to work on lots of other installations. If that's the case, there's a possibility it's something we can work around.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
This is apache, right? What version? I only tested apache2, though.
OS: Fedora 1 I' using apache 2.0.48, cgi 3.00
I was running the buglist.cgi with perl and I got the following results: Set-Cookie: Bugzilla_login=1; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT Set-Cookie: Bugzilla_logincookie=43; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT HTTP/1.0 200 OK Server: cmdline Date: Sat, 22 Nov 2003 11:42:38 GMT Filename: bugs-2003-11-22.html Content-Type: multipart/x-mixed-replace;boundary="------- =_aaaaaaaaaa0" WARNING: YOUR BROWSER DOESN'T SUPPORT THIS SERVER-PUSH TECHNOLOGY. --------- =_aaaaaaaaaa0 ... Expected was: Set-Cookie: Bugzilla_login=1; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT Set-Cookie: Bugzilla_logincookie=45; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT Content-disposition: "inline; filename=bugs-2003-11-22.html" Content-Type: multipart/x-mixed-replace;boundary="------- =_aaaaaaaaaa0" WARNING: YOUR BROWSER DOESN'T SUPPORT THIS SERVER-PUSH TECHNOLOGY. --------- =_aaaaaaaaaa0 Content-Type: text/html <!-- 1.0@bugzilla.org -->
I did some more investigation and I found the problem but I don't see a simple solution currenlty (except for changing perl CGI: Inside multipart_init the parameters are stored in a hash at some time, depending on the order the parameters are processed (ramdomly due to hashing). If the parameters are collected back, the parameter order gets corrupted and the 'nph' value will be the content of the next parameter. In my optinion this is a bug in perl CGI or perl itself (order of values) and should be fixed there.
This attachment will fix the issue, I will open a bug against perl 5.8.1 to get this working permantly. be aware that this is a patch against your perl installation, I didn't checked if there're side effects.
This patch rewrites the multipart_init function in CGI.pm instead of patching perl 5.8.1 itself. This would help until a working CGI.pm function is available again. BTW: Please read the release notes of perl 5.8.1 about randomization of hashes which describes why this happens only from time to time ...
Attachment #136107 - Attachment is obsolete: true
Sorry for this but there's a ',' in the use list (line 26) after applying the patch, Please remove this before testing the patch...
I'm confused: > If the parameters are collected back, the parameter order gets corrupted and the > 'nph' value will be the content of the next parameter. Why does this affect anything? I can reproduce this locally, so it obviously does. Is the issue that the call to $self->header then has the 'second' nph param come before teh 'first', so the -nph=>1 overrides it? multipart_init calls CGI::header, and passes through an array, with the 'second' nph afterwards. CGI::header takes that as @p, and passes it through to rearrange. CGI::Util::rearrange goes through @param in array order, not hash order. Where does it depend on the hash key iteration order?
The problem is that multipart_init also calls CGI::Utils::rearrange and all unknown parameters are changed to 'key=value' pairs; if there's no value , the key keeps as it is, i.e. after calling rearrange the first time, there's something like: ..., content_disposition='inline; filename...', nph or ..., nph, content_disposition='inline; filename...' In the first case the second call will unset the nph value, in the second case the second call to rearrange will set return 'content_disposition='inline; filename...'' as the value of nph, which results to 'true' in the header function. The last patch provided should fix the issue at least until they change the behavior of multipart_init in perl's CGI.
hmm. OK. Have you submitted thsi patch upstream?
Status: UNCONFIRMED → NEW
Ever confirmed: true
We just upgraded Landfill to Fedora Core 1, and got bit by this.
The perl bug is still open even with priority high. Meanwhile there's a corrected patch.
Attachment #136312 - Attachment is obsolete: true
btw... I do not have write access to CVS (didn#t had the time to manage it). Somebody else should apply the patch
Attachment #139342 - Flags: review?(bbaetz)
Comment on attachment 139342 [details] [diff] [review] Fixed patch of above If you mail teh CGI.pm author directly, you'll usually get a response back within a few days. r=bbaetz with a comment mentioning what the issue is. When CGI.pm gets fixed, we'll back this out and up the required version.
Attachment #139342 - Flags: review?(bbaetz) → review+
Assignee: justdave → sr
Flags: approval?
a= justdave It'd be really nice to get this pushed upsteam... we probably need to reimplement most of the multipart-* stuff by the look of it. Given that it's a (so far) Gecko-specific feature, we're the perfect organization to contribute a fix to CGI.pm for it. :)
Flags: approval? → approval+
Target Milestone: --- → Bugzilla 2.18
i had a longer mailchat with the CGI.pm maintainer last week and he was asking why not simply to change multipart_init to use nph=>0 or a configurable parameter. I didn't got the last response from him. Please put the change into CVS until we get a new CGI.pm version. I will follow up with an enhancement once this issue is fixed in CGI.pm. Comment for CVS should be something like: Due to randomization of perl hash table functionality since 5.8.1 the 'hack' to unset the nph parameter for multipart messages is not working reliable, insteat a modified clone of the original multipart_init function is setting this parameter to '0' and is ignoring the given nph parameter from buglist.cgi.
Status: NEW → ASSIGNED
Checking in CGI.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/CGI.pm,v <-- CGI.pm new revision: 1.8; previous revision: 1.7 done
Status: ASSIGNED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Checking in this patch broke test 005, as the checked in patch had tabs.
Checking in CGI.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/CGI.pm,v <-- CGI.pm new revision: 1.9; previous revision: 1.8 done
A regression of this got fixed in bug 238683.
CGI version 3.05 has been released. We should, when this release is in use more frequently rollback the changes for this issue and rely on the original CGI.pm code.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: