[02:30:29] TimStarling: I misread or misunderstood part of what you said regarding HTTP 1.0 and our content-length output. Not only does it exist for suporting HTTP 1.0, it only actually does something on HTTP 1.0. Our emitContentLength method literally does nothing unless it is 1.0. I didn't realize that originally [02:30:57] so I guess that means in production with mw's own compression turned off, the output buffer literally doesn't do anything, other than serve as a way to reset it. [02:31:08] not even to set content-length [02:33:01] As part of T140664, I was hoping we could remove support for disabling outputpage / resetting output buffers [02:33:04] T140664: Prepare MediaWiki for API-driven frontend - https://phabricator.wikimedia.org/T140664 [02:33:31] (other than e.g. within the API / OutptuPage / load.php for itself to replace its own response in case of an exception, but we don't use native output buffers for any of that) [02:37:26] the idea being that instead of Special:Export requests being routed internally as a page view with a skin and output page and then backing out of it, instead it would instead communicate that in a more declarative way. could be as basic as a boolean method that MediaWiki.php checks for early on to know that this is a custom response. This could then be iterated on to build a routing map of sorts. Moving this out of Special:* would of [02:37:26] course be nice as well, I don't know if this is the only one. Either way the principle/outcome would be that we don't support disabling output page and have a clean routing map (either a relatively simple, or a more complex one based on special pages able to opt out) [02:38:14] depends on how iterative/ambitious we want to be [03:32:32] $wgDisableOutputCompression is false in production [03:34:18] otherwise, yes that's right, it was doing nothing unless it is 1.0 [03:34:43] Aaron's patch made it do something on 1.1, and also broke the $wgDisableOutputCompression hack which made it work for Special:Export [03:34:50] that's why it broke [03:35:54] as for getting rid of wfResetOutputBuffers(), sure, why not [03:37:48] I'm interested in fixing this patch because I merged it, which I figure gave me some responsibility for it, but I'm not working on anything else related right now [04:21:30] TimStarling: wgDisableOutputCompression being false that can't be right [04:21:32] but you are [04:21:51] I'm 99% sure we don't however "do" compression on app servers despite this [04:22:02] We used to set this to true in 2016 and even until recently [04:22:14] Maybe we cleaned it up because we now prevent this at the ATS level instead [04:22:21] by not ever telling it we support gzip encoding [04:29:21] some background: T125938 , https://phabricator.wikimedia.org/T189966#4309514 , T242478, and a few ohers I can't find right now [04:29:22] T125938: PHP fatal errors causing Varnish to return 503 - "Junk after gzip data" - https://phabricator.wikimedia.org/T125938 [04:29:22] T242478: Production load.php spends ~ 10% time doing output compression within PHP - https://phabricator.wikimedia.org/T242478 [04:29:50] though that was in essence all just genuine bugs of course on our side, e.g. sending gzipped empty string on 304 or 204 responses [04:30:01] and there is T263288 to propose re-enabling this [04:30:01] T263288: experiment with reenabling compression between applayer's TLS terminators and edge caches - https://phabricator.wikimedia.org/T263288 [04:30:15] but not within MW [04:32:34] anyway, I'm not advocating to remove the feature. It's easy to keep something like this around if we can keep it standalone and without anything else having to worry or be aware of it.