User "Ilmari Karonen" posted a comment on MediaWiki.r97851. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97851#c23067 Commit summary:
followup r79862: the for loop only cleans up half the output handlers (since $i counts up while ob_get_level() counts down); check the return value of ob_end_clean() instead. (I just noticed this while eyeballing the code -- apparently most people don't have multiple output handlers active, given that nobody had caught this in over eight months.) Comment: It turns out that the whole loop could and probably should be replaced by a call to <code>wfClearOutputBuffers()</code>. Oh, and it should probably do <code>ini_set( 'zlib.output_compression', 0 )</code> too. ---- Ps. I tried looking a bit deeper, and found what looks like a real mess. Apparently there are at ''least'' three slightly different and incompatible ways to gzip-compress the output of MediaWiki (zlib.output_compression, ob_gzhandler and MediaWiki's own wfOutputHandler) and what seem to be the ancient remnants of a fourth ($wgUseGzip). It also seems that they ''all'' suffer (or at least used to suffer in some PHP versions) of similar bugs that require disabling them before an HTTP 304 response is sent. wfClearOutputBuffers() correctly does that for two of them, but not for zlib.output_compression, which needs a separate ini_set() call. Oh, and there's a whole bunch of places in MediaWiki that send 304 responses, and currently only one of them (OutputPage::checkLastModified()) seems to handle all the cases right. Eurgh. Some references/bookmarks: bug 8148 / r18253, bug 26130 / r78199, bug 26370 / r79862. _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
