[wp-trac] [WordPress Trac] #33626: wp_favicon_request() may set a bad value for Content-Length header
WordPress Trac
noreply at wordpress.org
Tue Sep 1 07:08:04 UTC 2015
#33626: wp_favicon_request() may set a bad value for Content-Length header
--------------------------+------------------------------
Reporter: martiusweb | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 3.0
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by dd32):
> If output buffering (what I incorrectly called ob_cache in my first
message) is disabled, Content-Length won't be set, and the HTTP message
will not contain an erroneous Content-Length header value. I think only a
warning will be logged (and/or displayed).
Correct, A Warning is issued as PHP had already started outputting the
page (So the `Content-Length` & `Content-Type` headers can't be sent).
This effectively breaks all `Location:` redirects & cookies used by
WordPress.
WordPress doesn't enable output buffering, but it's sometimes enabled from
within PHP (which it will be in this case I expect).
So while clearing the output buffer before exiting in this function might
help, it doesn't actually fix the issue for a lot of users.
I feel that we should instead remove the `Content-Length: 0` header
allowing the web server to determine the appropriate length.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/33626#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list