[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