Intermittent content-type of "application/octet-stream" prompts download window in Firefox
Closed, ResolvedPublic

Description

Author: list

Description:
Server: SuSE 9.1 pro, Apache 2.0.49, PHP 4.3.4, SSL.
Client: Firefox 1.0 (Windows and Linux)

Periodically (about one in ten requests) will result in firefox prompting to download the index.php
as an "application/octet-stream". The problem seems most frequent when clicking an Edit link,
however viewing articles directly will also trigger it sometimes. Problem is intermittent in that
the same link will sometimes work fine. Additionally, a moderate percentage of page views take up
to a minute to return from the server. Of these, some return normal pages, and some have the
download problem.

The problem appears to happen only over https (OpenSSL). Via http, the problem is not seen.

The problem only happens in Firefox. IE and Konquerer both seem okay.

No errors are logged on the server.

I have also tested on a SuSE 9.2 server with Apache 2.0.50 and PHP 4.3.8, same result. I have also
tested with MediaWiki-1.3.9, same result.


Version: 1.4.x
Severity: normal
OS: Linux
Platform: PC

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz1109.
bzimport created this task.Via LegacyDec 15 2004, 11:59 PM
bzimport added a comment.Via ConduitDec 16 2004, 12:33 AM

list wrote:

Just some further notes:

  • Other PHP applications are running successfully over SSL on this machine, with no similar issues.
  • Have tried with and without memcached.

I'm interested to know if others can duplicate this behavior.

bzimport added a comment.Via ConduitDec 16 2004, 6:20 PM

list wrote:

The stream that firefox is prompting to save appears to be a gziped file of some
sort? Headers follow, and I've attached the full file (binary).

HTTP/1.1 200 OK
Date: Thu, 16 Dec 2004 18:01:34 GMT
Server: Apache/2.0.49 (Linux/SuSE)
X-Powered-By: PHP/4.3.4
Set-Cookie: PHPSESSID=9e101ab5143e451d11f0eebae4e6225c; path=/
Content-language: en
Vary: Accept-Encoding,Cookie
Expires: -1
Cache-Control: private, must-revalidate, max-age=0
Content-Encoding: gzip
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

bzimport added a comment.Via ConduitDec 16 2004, 6:22 PM

list wrote:

Sample downloaded content stream.

Attached: index.php.test2

bzimport added a comment.Via ConduitDec 16 2004, 6:43 PM

list wrote:

My last comment led me to look at the output compression options in mediawiki.
Commenting out the compression line (20) in LocaSettings.php solved the

symptoms, if not the problem.

    1. Compress output if the browser supports it
  1. if( !ini_get( 'zlib.output_compression' ) ) @ob_start( 'ob_gzhandler' );

My guess is that the SSL host is not configured to handle the compressed output
in the same way that the normal http host is, even though they're part of the
same Apache installation, but that's about the extent of my understanding at
this point.

bzimport added a comment.Via ConduitMar 31 2005, 7:54 PM

rcordray wrote:

I've been having this same problem with MediaWiki 1.4.0 (final version) running on Apache 1.3.33 (PHP 4.3.10) and Firefox 1.02 on Windows. I'm *not* running SSL. I tried changing the default MIME type on Apache to application/octet-stream, but the reported behavior still happens. Weird.

brion added a comment.Via ConduitMay 27 2005, 7:07 PM
  • Bug 2256 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 27 2005, 7:23 PM

river wrote:

some users have reported similar behaviour on WMF sites, although not
over SSL. i looked at the contents of the stream and it seems to be gzip
compressed, but the content was corrupted (it was obviously a monobook
page, but the contents were mangled somehow). this may have been related
to smellie's later memory problems, though, rather than a software or
configuration issue...

speak to sj if you want more information about this, he has been seeing
it a lot.

bzimport added a comment.Via ConduitMay 28 2005, 10:12 AM

klemenkocjancic wrote:

I've problems on Win XP Pro SP2 (Slovenian add.). Klemen Kocjancic

bzimport added a comment.Via ConduitMay 29 2005, 9:43 AM

klemenkocjancic wrote:

I tried to open a
http://sl.wikipedia.org/wiki/Lemuel_Cornick_Shepherd_mlaj%C5%A1i and got this on
page:

<html><body></body></html>

brion added a comment.Via ConduitMay 29 2005, 9:45 AM

When you see <html><body></body></html> in Mozilla or Firefox's "View Source" window,
that is not actually what was sent. That's inserted mysteriously by Mozilla when the
document actually had no contents at all or some other problem occurred.

bzimport added a comment.Via ConduitMay 30 2005, 1:48 PM

klemenkocjancic wrote:

I don't know if this is the same bug...

I was working on
http://sl.wikipedia.org/w/index.php?title=Seznam_glasbenih_vsebin&action=submit
and got this (plus on other pages):

Warning: mysql_query(): Unable to save result set in
/usr/local/apache/common-local/php-1.4/includes/Database.php on line 349

Warning: mysql_query(): Unable to save result set in
/usr/local/apache/common-local/php-1.4/includes/Database.php on line 349
Error in fetchObject(): Server shutdown in progress

Backtrace:

  • GlobalFunctions.php line 510 calls wfbacktrace()
  • Database.php line 505 calls wfdebugdiebacktrace()
  • Parser.php line 3087 calls databasemysql::fetchobject()
  • Parser.php line 182 calls parser::replacelinkholders()
  • GlobalFunctions.php line 1149 calls parser::parse()
  • SkinTemplate.php line 321 calls wfgetsitenotice()
  • OutputPage.php line 429 calls skinmonobook::outputpage()
  • OutputPage.php line 636 calls outputpage::output()
  • Database.php line 386 calls outputpage::databaseerror()
  • Database.php line 333 calls databasemysql::reportqueryerror()
  • Parser.php line 3081 calls databasemysql::query()
  • Parser.php line 182 calls parser::replacelinkholders()
  • OutputPage.php line 239 calls parser::parse()
  • OutputPage.php line 233 calls outputpage::addwikitexttitle()
  • Article.php line 1182 calls outputpage::addwikitextwithtitle()
  • Article.php line 1145 calls article::showarticle()
  • EditPage.php line 313 calls article::updatearticle()
  • EditPage.php line 68 calls editpage::editform()
  • EditPage.php line 164 calls editpage::edit()
  • index.php line 176 calls editpage::submit()
bzimport added a comment.Via ConduitMay 30 2005, 3:16 PM

timwi wrote:

Periodically (about one in ten requests) will result in firefox prompting to

download the

index.php as an "application/octet-stream".

This problem has existed at least since 1.3, and in my opinion it is unrelated
to SSL (because I've never been using SSL) and also to gzip (because every
response uses that, not just those that exhibit the problem).

Back when I set up CambridgeWiki, I had the problem constantly. About 1 in 3
requests would exhibit the problem. With newer versions, this seems to have gone
down, and it is now running 1.3.7.

However, recently the problem has come up more and more on Wikimedia's own
servers. I see it about once in every 10 to 20 requests, but it is more common
with &action=edit/history/diff; very rarely when just viewing an article.
Unfortunately, since the problem is unpredictable, it is not reproducible, and
as such, I cannot show you the response headers sent by the server when it happens.

bzimport added a comment.Via ConduitJun 9 2005, 5:31 PM

zigger wrote:

(In reply to comment #11)

I don't know if this is the same bug...
...

That looks like bug 2159.

bzimport added a comment.Via ConduitJun 9 2005, 6:39 PM

gangleri wrote:

incompatibility in "product" between
MediaWiki: bug 1109 Intermittent content-type of "application/octet-stream"
prompts download window in Firefox
Wikimedia web sites: bug 2159: http://en.wikipedia.org/wiki/Special:Allpages not
working


question: How "vote limitation" is handeled at bugzilla if a bug is "moved" to
another "product"?

Regards Reinhardt [[user:gangleri]]

bzimport added a comment.Via ConduitJun 9 2005, 7:22 PM

zigger wrote:

Uncompressed page from previous attachment

(In reply to comment #7)
If the first body line is removed (3 characters long: bdf), the file can be
uncompressed ok (attached).

Attached: index.php.test2.html

bzimport added a comment.Via ConduitJun 28 2005, 10:26 PM

davids_s wrote:

Anybody working on this, this is really annoying.

brion added a comment.Via ConduitJun 30 2005, 10:54 PM

I've still had no success actually reproducing this problem on Wikimedia's servers
or my test servers, but was able to confirm it on someone else's server and took
some network packet captures to try to figure it out.

The client-side problem may be this Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=197426

With output compression on, MediaWiki ends up sending a little bit of data (an
empty gzip header) along with for instance '304 Not Modified' responses which are
not supposed to have any data[1]. Under some circumstances this seems to confuse
Mozilla/Firefox, with the results as seen above.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5

The deadly combination seems to be:

  • HTTP 1.1 persistent connections (Keep-Alive on in Apache config)
  • PHP's ob_gzhandler engaged in LocalSettings.php
  • Splitting HTTP headers and the data block across two packets
  • SECRET INGREDIENT: Slowness/size/multiple requests/something??

<speculation>
Since data isn't expected with a 304 response anyway, Mozilla may be considering
the request done at the end of the packet. When interpreting results for the next
request on the connection, it ends up seeing the extra data from the previous
request before the headers.

It apparently assumes the server just made a wee little mistake and forgot to send
any headers, and treats the data+headers+data as a single set of returned data
such as the attached sample stream. Since it looks binary, it offers to download
rather than display as text inline.
</speculation>

I'd like anybody experiencing this with their server to try the following, in
turn:

a) Try turning off keepalive in httpd.conf:

  1. KeepAlive: Whether or not to allow persistent connections (more than
  2. one request per connection). Set to "Off" to deactivate. #

KeepAlive Off

(If it's _on_ and you're still having this problem, let me know.)

b) Disable output compression in MediaWiki:

Compress output if the browser supports it

/* if( !ini_get( 'zlib.output_compression' ) ) @ob_start( 'ob_gzhandler' ); */

c) Try turning those two back on and apply the experimental patch I'm attaching.
This will prevent that extra empty compressed data blob from being output on 304
Not Modified responses.

brion added a comment.Via ConduitJun 30 2005, 10:55 PM

Created attachment 659
Adds an ob_end_clean() call on 304 Not Modified returns

Please test this patch if experiencing this problem on your server.

Attached: output-caching-patch.diff.txt

brion added a comment.Via ConduitJul 4 2005, 10:44 PM

No feedback given so far.

I'm marking this FIXED provisionally; I've committed the path on CVS HEAD and it's been live for a few days.

bzimport added a comment.Via ConduitNov 5 2006, 7:49 PM

steffe62 wrote:

This problem happend to me for the first time last Saturday (October 28th). It's
the same problem as #12. It only happens in monobook. For the last couple of
days I run simple.css and that is no problem. But when switching to monobook I
get, for example:

You have choosen to open
Special:Recentchanges
which is a: application/octet-stream
from: http://sv.wikipedia.org
Would you like to save this file?"

It happens about every 10 request, and to any kind of action (edit, article,
recent changes..., new article).

Firefox 2.0, but also in 1.5.

//StefanB on Swedish Wikipedia http://sv.wikipedia.org/wiki/User:StefanB

bzimport added a comment.Via ConduitNov 5 2006, 8:14 PM

steffe62 wrote:

attachment to #20

Attached: index.php

bzimport added a comment.Via ConduitNov 5 2006, 8:15 PM

steffe62 wrote:

attachment 2 to #20

Attached: Special-Recentchanges

bzimport added a comment.Via ConduitNov 5 2006, 8:33 PM

steffe62 wrote:

new attachement to #20

Attached: index.php

bzimport added a comment.Via ConduitNov 5 2006, 8:34 PM

steffe62 wrote:

new attachement 2 to #20

Attached: Special-Recentchanges

brion added a comment.Via ConduitNov 5 2006, 8:41 PM

Both of these are gzipped with empty contents; that sounds like the (supposedly
fixed) problem I mention above, should check if we've had a regression...

brion added a comment.Via ConduitNov 5 2006, 10:34 PM

The original fix broke due to an additional output buffer layer being added recently on our servers;
only the topmost buffering layer was canceled, so the compression handler was now left running and
started appending its junk again.

I've improved the fix in r17452 to peel back *all* output buffers, which should get things happy again.

StefanB, please confirm if this resolves things for you.

bzimport added a comment.Via ConduitNov 6 2006, 2:28 AM

steffe62 wrote:

Yes, I've clicked about 100 links without having the problem, so it seems to be
fixed. Thank you.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.