Page MenuHomePhabricator

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

Assigned To
None
Authored By
bzimport
Dec 15 2004, 11:59 PM
Referenced Files
F1751: Special-Recentchanges
Nov 21 2014, 8:06 PM
F1750: index.php
Nov 21 2014, 8:06 PM
F1748: index.php
Nov 21 2014, 8:06 PM
F1749: Special-Recentchanges
Nov 21 2014, 8:06 PM
F1747: output-caching-patch.diff.txt
Nov 21 2014, 8:06 PM
F1746: index.php.test2.html
Nov 21 2014, 8:06 PM
F1745: index.php.test2
Nov 21 2014, 8:06 PM
Subscribers
None

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

Details

Reference
bz1109
ReferenceSource BranchDest BranchAuthorTitle
repos/phabricator/deployment!7work/2023-03-30-releasewmf/stablebrennenupdate submodules for other assignees, MR widget, SVN URI generation
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:06 PM
bzimport set Reference to bz1109.
bzimport added a subscriber: Unknown Object (MLST).

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.

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

list wrote:

Sample downloaded content stream.

Attached:

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.

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.

  • Bug 2256 has been marked as a duplicate of this bug. ***

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.

klemenkocjancic wrote:

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

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>

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.

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()

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.

zigger wrote:

(In reply to comment #11)

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

That looks like bug 2159.

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]]

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:

davids_s wrote:

Anybody working on this, this is really annoying.

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.

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:

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.

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

steffe62 wrote:

attachment to #20

Attached:

steffe62 wrote:

attachment 2 to #20

Attached:

steffe62 wrote:

new attachement to #20

Attached:

steffe62 wrote:

new attachement 2 to #20

Attached:

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...

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.

steffe62 wrote:

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