Closed
Bug 226251
Opened 21 years ago
Closed 20 years ago
internal error when server push is enabled
Categories
(Bugzilla :: Query/Bug List, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: sreindl, Assigned: sreindl)
Details
Attachments
(2 files, 2 obsolete files)
1.45 KB,
patch
|
bbaetz
:
review+
|
Details | Diff | Splinter Review |
700 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•21 years ago
|
Version: unspecified → 2.17.6
Comment 1•21 years ago
|
||
*** This bug has been marked as a duplicate of 226249 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 2•21 years ago
|
||
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
Comment 3•21 years ago
|
||
turn off mod_perl. Bugzilla doesn't work with it yet.
Assignee | ||
Comment 4•21 years ago
|
||
I disabled mod_perl some days ago ... :-(
Comment 5•21 years 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(@_); }
Assignee | ||
Comment 6•21 years ago
|
||
not in my installation, btw should we reopen this issue
Comment 7•21 years ago
|
||
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...
Comment 8•21 years ago
|
||
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...
Comment 9•21 years ago
|
||
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 → ---
Comment 10•21 years ago
|
||
This is apache, right? What version? I only tested apache2, though.
Assignee | ||
Comment 11•21 years ago
|
||
OS: Fedora 1 I' using apache 2.0.48, cgi 3.00
Assignee | ||
Comment 12•21 years ago
|
||
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 -->
Assignee | ||
Comment 13•21 years ago
|
||
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.
Assignee | ||
Comment 14•21 years ago
|
||
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.
Assignee | ||
Comment 15•21 years ago
|
||
Corresponding perl ticket: http://rt.perl.org/rt2//Ticket/Display.html?id=24542
Assignee | ||
Comment 16•21 years ago
|
||
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 ...
Assignee | ||
Updated•21 years ago
|
Attachment #136107 -
Attachment is obsolete: true
Assignee | ||
Comment 17•21 years ago
|
||
Sorry for this but there's a ',' in the use list (line 26) after applying the patch, Please remove this before testing the patch...
Comment 18•21 years ago
|
||
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?
Assignee | ||
Comment 19•21 years ago
|
||
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.
Comment 20•21 years ago
|
||
hmm. OK. Have you submitted thsi patch upstream?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 21•21 years ago
|
||
We just upgraded Landfill to Fedora Core 1, and got bit by this.
Assignee | ||
Comment 22•21 years ago
|
||
The perl bug is still open even with priority high. Meanwhile there's a corrected patch.
Attachment #136312 -
Attachment is obsolete: true
Assignee | ||
Comment 23•21 years ago
|
||
btw... I do not have write access to CVS (didn#t had the time to manage it). Somebody else should apply the patch
Updated•21 years ago
|
Attachment #139342 -
Flags: review?(bbaetz)
Comment 24•21 years ago
|
||
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+
Updated•20 years ago
|
Assignee: justdave → sr
Flags: approval?
Comment 25•20 years ago
|
||
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+
Updated•20 years ago
|
Target Milestone: --- → Bugzilla 2.18
Assignee | ||
Comment 26•20 years ago
|
||
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
Comment 27•20 years ago
|
||
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: 21 years ago → 20 years ago
Resolution: --- → FIXED
Comment 28•20 years ago
|
||
Checking in this patch broke test 005, as the checked in patch had tabs.
Comment 29•20 years ago
|
||
Comment 30•20 years ago
|
||
Checking in CGI.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/CGI.pm,v <-- CGI.pm new revision: 1.9; previous revision: 1.8 done
Comment 31•20 years ago
|
||
A regression of this got fixed in bug 238683.
Assignee | ||
Comment 32•20 years ago
|
||
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.
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•