[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