r78199 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r78198‎ | r78199 | r78200 >
Date:17:06, 10 December 2010
Author:catrope
Status:ok
Tags:
Comment:
(bug 26130) ob_start( 'ob_gzhandler' ) in LocalSettings.php broke gzip output from load.php . This is caused by http://bugs.php.net/bug.php?id=36514 (ob_clean() removes GZIP header). Also noticed that load.php is affected by http://bugs.php.net/bug.php?id=51579 (ob_gzhandler generates non-empty 304s, invalid HTTP, triggers a Firefox bug) as well and fixed that too while I was at it.
Modified paths:
  • /trunk/phase3/includes/resourceloader/ResourceLoader.php (modified) (history)

Diff [purge]

Index: trunk/phase3/includes/resourceloader/ResourceLoader.php
@@ -287,6 +287,15 @@
288288 */
289289 public function respond( ResourceLoaderContext $context ) {
290290 global $wgResourceLoaderMaxage, $wgCacheEpoch;
 291+
 292+ // Buffer output to catch warnings. Normally we'd use ob_clean() on the
 293+ // top-level output buffer to clear warnings, but that breaks when ob_gzhandler
 294+ // is used: ob_clean() will clear the GZIP header in that case and it won't come
 295+ // back for subsequent output, resulting in invalid GZIP. So we have to wrap
 296+ // the whole thing in our own output buffer to be sure the active buffer
 297+ // doesn't use ob_gzhandler.
 298+ // See http://bugs.php.net/bug.php?id=36514
 299+ ob_start();
291300
292301 wfProfileIn( __METHOD__ );
293302
@@ -353,6 +362,19 @@
354363 if ( $ims !== false ) {
355364 $imsTS = strtok( $ims, ';' );
356365 if ( $mtime <= wfTimestamp( TS_UNIX, $imsTS ) ) {
 366+ // There's another bug in ob_gzhandler (see also the comment at
 367+ // the top of this function) that causes it to gzip even empty
 368+ // responses, meaning it's impossible to produce a truly empty
 369+ // response (because the gzip header is always there). This is
 370+ // a problem because 304 responses have to be completely empty
 371+ // per the HTTP spec, and Firefox behaves buggily when they're not.
 372+ // See also http://bugs.php.net/bug.php?id=51579
 373+ // To work around this, we tear down all output buffering before
 374+ // sending the 304.
 375+ while ( ob_get_level() > 0 ) {
 376+ ob_end_clean();
 377+ }
 378+
357379 header( 'HTTP/1.0 304 Not Modified' );
358380 header( 'Status: 304 Not Modified' );
359381 wfProfileOut( __METHOD__ );
@@ -363,13 +385,14 @@
364386 // Generate a response
365387 $response = $this->makeModuleResponse( $context, $modules, $missing );
366388
367 - // Tack on PHP warnings as a comment in debug mode
 389+ // Capture any PHP warnings from the output buffer and append them to the
 390+ // response in a comment if we're in debug mode.
368391 if ( $context->getDebug() && strlen( $warnings = ob_get_contents() ) ) {
369392 $response .= "/*\n$warnings\n*/";
370393 }
371394
372 - // Clear any warnings from the buffer
373 - ob_clean();
 395+ // Remove the output buffer and output the response
 396+ ob_end_clean();
374397 echo $response;
375398
376399 wfProfileOut( __METHOD__ );

Follow-up revisions

RevisionCommit summaryAuthorDate
r79129MFT r78011 r78014 r78015 r78016 r78099 r78117 r78161 r78170 r78172 r78199 r78......platonides19:58, 28 December 2010

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r77908(bug 26130) Revert changes to WebStart.php in r72349, which turn out to have ...catrope20:57, 6 December 2010

Status & tagging log