Safari issues with wp-includes/ms-files.php

[Brandicoot]

We have a multi-site network with over 200 sites on it.

Whilst the network is running WP 4.7.4–en_AU the network was originally built on a version prior to 3.5 and has been continually updated as versions become available. That being said, our network still uses the old file structure wp-content/blogs.dir/[site#]/files to store media. I've tried converting this over with no success and haven't really been able to find any good resources to help me do this beyond the things I've tried.

So, our network continues to use the above path with the compatibility option of using wp-includes/ms-files.php which is called in the .htaccess file.

However, there seems to be a bug in the ms-files.php that are causing some resources not to load properly when the sites are loaded into Safari or an iOS device.

1. PDF documents fail to load
2. CSS files that have been cached by our theme (it has it's own caching function) also fail to load.

I've narrowed down the culprit to the lines of code in ms-file.php that output the headers. If I comment out the code on line 43:

header( 'Content-Length: ' . filesize( $file ) );

...then the problem goes away. Not sure what impact commenting the above has but it doesn't seem to break the site so I've left it commented out.

My best guess is that Safari doesn't like this header being sent out separately from the earlier one on line 41. It may even be a bug with Safari - not sure on this one.

Anyway, thought I'd report it here to begin with.

Cheers
Chris

[talldanwp]

@Brandicoot, apologies there hasn't been a response to your ticket.

I realise 3 years has passed, so not sure if this is still an issue you're facing.

The ticket was discussed during a triage session (on slack, here's a link to the conversation, though it will require an account to view - ​https://wordpress.slack.com/archives/C02RQBWTW/p1595915178149000).

One of the comments there was:

This sounds like a server configuration failure, the server is probably compressing the result and failing to update the Content-Length header.. that might be why the IIS check is there..
Alternatively, unexpected output like whitespace after ?> in wp-config.php.

Anyway, just checking in to see whether you managed to solve the problem and whether this ticket is still valid.

[dd32]

I suspect the Content-Length header might be there so that HEAD requests get the correct response per the HTTP spec:
​https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

The behaviour being seen might also be a combination of the above, and the behaviour of the ios clients with the If-Modified-Since header..

It could also be a bad server compressing the output, but failing to update the Content-Length header (That might be why we don't send it for IIS).

And finally, as I mentioned on slack and quoted above, it could also have been more than just the file being output, such as whitespace after a closing ?> tag or something from a plugin.

I'd suggest removing the header is a viable solution, but it would probably break why it was originally added: ​https://mu.trac.wordpress.org/ticket/473

If anyone runs into this in the future, determining how much data is actually output vs what the filesize is might be beneficial.