[wp-trac] [WordPress Trac] #40631: Safari issues with wp-includes/ms-files.php
WordPress Trac
noreply at wordpress.org
Tue Jul 28 06:02:07 UTC 2020
#40631: Safari issues with wp-includes/ms-files.php
-------------------------------+------------------------------
Reporter: Brandicoot | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 4.7.4
Severity: normal | Resolution:
Keywords: reporter-feedback | Focuses: multisite
-------------------------------+------------------------------
Comment (by 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40631#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list