Topic on Project:Support desk

Tracked in Phabricator
Task T235554

I recently upgraded my wiki from MediaWiki 1.31 (PHP 7.3) to MediaWiki (PHP 7.4) on a shared hosting plan. We use the Extension:MobileFrontend. Since the upgrade a subset of my mobile device users (seems to be iPhone and iPad) are reporting that pages won't fully load and/or they get a "cannot parse response" error.

I cannot reproduce the problem on a localhost server (CentOS 8.2 with PHP 7.4).

We cannot reproduce the issue with a desktop browser (Chrome or Edge) DevTools emulating these devices, which is frustrating to say the least.

I've recreated my MediaWiki 1.31 in another directory on the shared hosting service and looked for differences in the network traffic. One difference we're noticed is that MediaWiki 1.35's initial header response includes a content-length parameter which isn't present when the same page is loaded from MediaWiki 1.31. We're using the Special:Version page for testing, so our wiki content isn't a factor (other than common interface elements such as logo and sidebar).

As a double-check, we checked the Special:Version page with The W3C Markup Validation Service and it reports "IO Error: Premature end of Content-Length delimited message body (expected: 55542; received: 11585" which we think might explain why the mobile devices are also giving an error.

I've tried changing the PHP version back to 7.3 for the MediaWiki 1.35 wiki and the problem persists.

Does MediaWiki 1.35 code include something that sets the Content-Length parameter in the HTTP headers? Is there a configuration setting involved?

If it helps, the wiki is at https://www.finiki.org

For the Project: support template:

MediaWiki	1.35.0
PHP	7.4.11 (cgi-fcgi)
MySQL	5.6.41-84.1

I forced the W3C Markup Validation Service check to use mobile view. The page has no output except for this single entry:

IO Error: Premature end of Content-Length delimited message body (expected: 51697; received: 11318 https://www.finiki.org/w/index.php?title=Special:Version&mobileaction=toggle_view_mobile

I can view the page in my desktop Chrome browser in both desktop and mobile views.

(This doesn't answer your question, but it's additional information to help identify the problem.)

Our installation:

MW1.35.0, PHP 7.4.3 (cgi-fcgi), MySQL 5.7.29-log

It works fine except that Safari users get a blank screen with a "NSPOSSIXErrorDomain:100" and iPads and iPhones also get blank screens. No error with Chrome on the Macs. Is this the upstream bug the MW 1.35 system requirements warn against "MediaWiki is not compatible with PHP 7.4.0 to 7.4.2 due to an upstream bug"?

To address the above point, I'm seeing the problem with PHP 7.4.11 so the not compatible issue mentioned in Compatibility does not apply. As mentioned, changing the PHP version back to 7.3.23 doesn't change the behaviour so I am thinking it is a MediaWiki related issue.

I've already worked though Manual:Common errors and symptoms and in particular the 'You see a Blank Page' section and it doesn't help identify any of the mentioned issues or help resolve the problem.

I don't know whether or not the HTTP header information for content-length appearing only with MediaWiki 1.35 and not with MediaWiki 1.31 on the same shared hosting server is a a symptom of the problem or a cause, but everything else that has been checked or investigated can explain why the Apple mobile devices are having issues with blank pages or giving "cannot parse response" errors.

Try setting $wgDisableOutputCompression = true;

MediaWiki will set a content length header if the HTTP version is 1.0 and gzipping is enabled

There are also certain situations where if MW wants to stay executing after it does output, and is not running as fast-cgi, where it will set a content-length header (4f11b614544be).

Made the change and now Apple mobile devices seem to be loading pages correctly. The W3C validator page isn't reporting an IO error. Thanks. This seems more like a workaround as I'd question why a default MediaWiki configuration setting needs to be overridden.

Did something in MediaWiki between 1.31 and 1.35 change MediaWiki's setting of a content length header if the HTTP version is 1.0 and gzipping is enabled? I had reviewed all the Release Notes between 1.31 and 1.35 looking for configuration changes that need to be considered and I don't recall seeing any indication of this change.

For reference sake, I've checked our PHP configuration and it is using the default zlib.output_compression = Off and cgi-fcgi which is an alternative PHP FastCGI implementation.

Based on what phpinfo reports, the Apple mobile devices are using HTTP/2.0.

$wgDisableOutputCompression is super old, way before mw 1.31. It might just be that http/2 is incompatible and its just recently that http/2 is starting to be enabled by default.

I've done some further testing on the testing environment that I'd setup to try and isolate the issue a bit further. The testing environment is running on the same shared hosting service and uses the last database backup when the wiki was running MediaWiki 1.31.10 (PHP 7.3.23, MySQL 5.6.41-84.1).

1. Running MediaWiki 1.31.10 the Special:Version and then two or three clicks of Random page
   1. Windows 10 desktop and using Edge Chromium ✔
   2. iPhone XR (iOS 14.1) Safari ✔
   3. iPad Pro (iPadOS 14.1) Safari✔
2. Upgraded to MediaWiki 1.32.6, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_32 versions).
   1. Windows 10 desktop and using Edge Chromium ✔
   2. iPhone XR (iOS 14.1) Safari ✔
   3. iPad Pro (iPadOS 14.1) Safari✔
3. Upgraded to MediaWiki 1.33.4, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_33 versions).
   1. Windows 10 desktop and using Edge Chromium ✔
   2. iPhone XR (iOS 14.1) Safari ✔
   3. iPad Pro (iPadOS 14.1) Safari✔
4. Upgraded to MediaWiki 1.34.4, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_34 versions).
   1. Windows 10 desktop and using Edge Chromium ✔
   2. iPhone XR (iOS 14.1) Safari ✔
   3. iPad Pro (iPadOS 14.1) Safari✔
5. Upgraded to MediaWiki 1.35.0, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_35 versions).
   1. Windows 10 desktop and using Edge Chromium ✔
   2. iPhone XR (iOS 14.1) Safari - spinning wheel and Special:Version never loads
   3. iPad Pro (iPadOS 14.1) Safari - spinning wheel and Special:Version never loads

Clearly something has changed between MediaWiki 1.34.4 and MediaWiki 1.35.0 that is causing problems for Apple devices for my wiki. Checking Release notes/1.35 there is an item:

• Fix GuzzleHttpRequest request headers.

There is no Task link for this, so I cannot trace it any further. Perhaps someone with more knowledge could locate the changes and review them to see if they could be responsible for the issue I'm seeing.

There is also:

• Updated guzzlehttp/guzzle from 6.3.3 to 6.5.4.

I can confirm the problem after upgrading my Wiki to 1.35. Interestingly only the "frame" of the pages was missing (logo, menu, search field etc.), the content part was visible.

The solution $wgDisableOutputCompression = true; worked. I post this because the thread is lacking the error code NSURLErrorDomain:-1017 which I had been googling, and others might do it too.

After updating my iPhone and iPad to 14.2 the problem persists. I also had the opportunity to test this using iPadOS 13.3 and the wiki loads and functions properly.

Based on the various testcases I've now run it leads me to believe there is some serious MediaWiki 1.35, Extension:MobileFrontend and Skin:MinervaNeue and iOS (iPadOS) 14.x interaction problem.

Filed bug report, ⚓ T267619 MediaWiki 1.35 with Extension:MobileFrontEnd and Skin:MinervaNeue seem to have problems with iOS 14 devices if output_compression is enabled (wikimedia.org)

The Guzzle things won't be relevant. MediaWiki uses Guzzle for making HTTP requests to other sites/services, rather than serving to users

I just noticed Redirection fails in Webikit browsers with NSPOSIXErrorDomain: 100 on Project:Support desk (mediawiki.org) that seems to describe similar issues.

Have your or anyone else tested MediaWiki 1.35 under either an Android device or an iPhone/iPad running 12.4.9, the latest version (i.e. newly and recently released) of iOS 12 for iPhones and iPads not compatible with iOS/iPadOS 13 or 14?

Other wiki users have tested and reported, "Samsung Android, OS 8.0.0, latest patches, Chrome browser.... works just fine." and "Pixel 3A with Android 11 and Chrome. Seems to work.".

I cannot report anything further because I had to implement the $wgDisableOutputCompression = true; workaround. Given that an Apple device using iPadOS 13.3 didn't have issues I'm guessing the anything pre-iOS 14 is okay and the specific problem is specific to MediaWiki 1.35 and iOS 14. Running a search for OS 14 on Wikimedia Phabricator shows lots of results.

A note of caution to anyone using the $wgDisableOutputCompression = true; workaround. I updated our wiki to MediaWiki 1.35.1 and for reasons I've been unable to figure out, there is some interaction between the setting and my shared hosts webserver configuration that results in pages being displayed as random symbols (encoding error). I works fine on my localhost testbed.

One the production site the only solution was to comment out the $wgDisableOutputCompression = true; so I'm back to the original problem, iPhones and iPads running iOS 14.x can never load any of our wiki pages.

Appropriate bug reports have been updated to reflect this information.

as of upgrading to 1.35.1 im getting the same result as above, pages being displayed as random symbols (encoding error) in Safari, Internet explorer, Edge and Chrome. Mozilla Firefox works fine..

Setting $wgDisableOutputCompression = true; gave no solution

Tested PHP 7.3 and 7.4

Any other ideas?

The $wgDisableOutputCompression = true;fixed a very similar problem at my completely new MW system, which had a nasty content-length mismatch which caused white pages in chrome and safari (desktop), Firefox worked. Main problem was that the content-length mismatch troubled the reverse proxy in front of MW.

I've had the same issue, and setting $wgDisableOutputCompression = true; appears to fix it.

I am having the same issue. If I set $wgDisableOutputCompression = true; then I get a bunch of random symbols and errors. I have also tried adjusting my $wgServer and $wgCanonicalServer. I'm not sure if that is the right area to work on but that also did not work.

This is what I did for the server:

$wgServer = "//quik.wiki";

$wgCanonicalServer = "https://quik.wiki";

EDIT:

Adding that the Chrome app on my iPhone also does not work. The load bar gets about half way, everything freezes, then I get a site cannot be reached error. I have no idea what's going on. My site works fine in Chrome on PC.

EDIT #2

I removed $wgCanonicalServer and kept $wgServer as //sitename and now both Safari and Chrome work, HOWEVER, they load on unsecure pages. If I add the https , the problems appear again. I'd like to have all my pages with https so this is only a temporary solution.

After upgrading to 1.35.1. in the Softaculous auto-installer in my Namecheap cPanel, all text is garbled symbols. The ONLY way to make my wiki (https://beijerpedia.com/wiki/Home) work again is the fix mentioned at:

https://www.mediawiki.org/wiki/Topic:Vzxi8uroe2eo23gk

---

Temporary fix:

Comment out exactly this line:

$response->header( 'Content-Encoding: identity' );

in: includes/MediaWiki.php

Nothing in this topic is working for iOS devices. Very few help topics for this I can find for such a monumental bug which prevents a huge swath of people from accessing the software via apple mobile. Can anyone shed light on a definitive answer?

@Longjebb to the best of my knowledge and experience with my wiki this remains unsolved. From my reading of the discussion, some admins have had success changing MediaWiki code as a workaround, but that a) isn't widespread and b) right or wrong, my admin policy is to ONLY use officially released software on my websites. The published workarounds might work for some but unless they get released by the MediaWiki development team as a maintenance fix or perhaps a hotfix, then I'm not using them.

Given the severity of T235554 I had hoped this would be resolved and a maintenance release containing a fix would have come sooner. As an Apple device user I'm stuck waiting on the resolution.

Thanks for the info. I am ready to roll a MW site which will get tens of thousands of visitors a week and can't launch until this is remedied for good. Not a great first experience w this software!

@Longjebb have you considered using MediaWiki 1.31.x which according to Version lifecycle is a current long-term support (LTS) version that will be supported until June 2021. My wiki was running very smoothly on 1.31 before we upgraded to 1.35.

Not sure I feel comfortable with a downgrade. Also a fan of getting it officially patched.

Can anyone shed light on whether or not a fix for this issue will be released....either via patch or next release? Not getting much traction mentioning on the discord support channel to date. Thanks!

I received notice today that T235554 has been marked as "Resolved". There are two commits on the REL1_35 branch.

I've never 'patched' my MediaWiki install so I'm trying to figure out what steps would be required to deploy the fix(es) on a MediaWiki 1.35.1 site.

Depends how you install/maintain MW....

There should be a Maintenance/Security release probably this week, but might be next week depending on schedules and progress. That will contain the fix for that resolved bug.

My wiki's are always installed/maintained using Download to provide the tar.gz file of the release.

Has there been any movement on this topic?

I've noticed the problem while using HTTPS on Safari, macOS 11 (HTTP seems to work, but I'd rather use the encrypted connection.)

wgDisableOutputCompression = true; produced a page of unreadable characters (like others have described above) and deleting $response->header( 'Content-Encoding: identity' ); in mediawiki.php had no effect.

What version of MediaWiki are you using? This should be fixed in 1.35.2, which was released at the start of April.

It would look like it was missed from 1.36 though :/

I skipped from 1.34.x to 1.36, so that's probably the problem. Has anybody tagged this as something that needs to be fixed for 1.36 and future versions?

It's been backported and merged. It will be in 1.36.1 (possibly at the end of the month).