Re: ob_gzhandler broken

From: Date: Fri, 23 Aug 2002 06:51:06 +0000
Subject: Re: ob_gzhandler broken
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-87338@lists.php.net to get a copy of this message
I completely agree. At 06:46 23/08/2002, Rasmus Lerdorf wrote:
I must be missing something. Why is this such a delicate issue? It's not a security problem, simply a bug like any other. Warrants a line in the NEWS file just like every other bug fix. -Rasmus On 22 Aug 2002, Xavier Spriet wrote: well I'm not part of the decision making process obviously but that statement sound good to me and since there will need to be an announcement made or at least a little intro for 4.2.3, I really don't see why this couldn't be part of it actually. On Thu, 2002-08-22 at 22:24, Brian Moon wrote:
    In my adventures with Phorum, I have found it best to just come clean.  No
    browsers that I know of have this issue, just this proxy.  Maybe some other
    proxies.  A statement:
    ob_gzhandler does not handle requests from some proxy server properly.  You
    are encouraged to upgrade your PHP or change to zlib.output_compression.
    That will not throw up any flags.  I mean, this has not been reported all
    this time.
    Brian.
    ----- Original Message -----
    From: "Xavier Spriet" <xavier@nextdimensioninc.com>
    To: "Brian Moon" <brian@phorum.org>
    Cc: "Zeev Suraski" <zeev@zend.com>; "Andreas Oesterhelt"
    <oes@oesterhelt.org>; <php-dev@lists.php.net>
    Sent: Thursday, August 22, 2002 9:13 PM
    Subject: Re: [PHP-DEV] ob_gzhandler broken
    | To the risk of looking quite indelicate concerning this matter, maybe a
    | direct hint in the announcement of 4.2.3 such as "Many serious
    | improvements and bug fixes (ob_gzhandler, etc...)" could make most users
    | want to upgrade without alarming anyone, thus avoiding unwanted bad
    | publicity and making the transition smoother for everyone ?
    | just a thought.
    |
    | On Thu, 2002-08-22 at 22:04, Brian Moon wrote:
    |
    |     Do you guys think that the users should be notified via a message on
    the
    |     front page that ob_gzhandler does not work in the current versions and
    that
    |     users should either upgrade (once fixed) or switch to
    |     zlib.output_compression?
    |
    |     Brian.
    |
    |     ----- Original Message -----
    |     From: "Zeev Suraski" <zeev@zend.com>
    |     To: "Brian Moon" <brian@phorum.org>
    |     Cc: "Andreas Oesterhelt" <oes@oesterhelt.org>; <php-dev@lists.php.net>
    |     Sent: Thursday, August 22, 2002 5:40 PM
    |     Subject: Re: [PHP-DEV] ob_gzhandler broken
    |
    |
    |     | Actually it's not that odd, looking at the source it appears that
    this is
    |     | exactly what is 'supposed' to happen.  I'll fix it.
    |     |
    |     | Zeev
    |     |
    |     | At 23:42 22/08/2002, Brian Moon wrote:
    |     | >There are two mechanisms for compressing output in PHP.  One is
    broke.
    |     The
    |     | >other works fine.
    |     | >
    |     | >You will see that phorum.org is now using the one that works.
    |     | >
    |     | >For the dev list:
    |     | >
    |     | >ob_gzhandler does do what this email says.  zlib.output_compression
    does
    |     | >not.  i would submit this to the bug list, but it seems that there
    are
    |     | >already several bugs about ob_gzhandler and that the general
    feeling is
    |     that
    |     | >it needs to be canned.
    |     | >
    |     | >Brian.
    |     | >phorum.org
    |     | >
    |     | >----- Original Message -----
    |     | >From: "Andreas Oesterhelt" <oes@oesterhelt.org>
    |     | >To: <brian@phorum.org>
    |     | >Sent: Wednesday, August 21, 2002 3:21 PM
    |     | >Subject: Phorum.org misconfigured?
    |     | >
    |     | >
    |     | >| Hi Brian,
    |     | >|
    |     | >| ..cathy subject, eh? Sorry to trouble you with this: Being a
    developer
    |     | >| of the soon-to-be-released Pivoxy HTTP proxy I stumbled accross a
    |     problem
    |     | >| our software is having with your (and other) sites and that I
    believe
    |     | >| is a fault in those sites' PHP/Apache setups.
    |     | >|
    |     | >| Every HTTP request that carries the (completely legal!) HTTP
    header
    |     | >| "Accept-Encoding: identity;q=1.0, *;q=0" is answered with a
    completely
    |     | >| empty response. Same goes for "Accept-Encoding:". Both are legal
    ways
    |     | >| to tell the server that we don't want the response compressed in
    any
    |     | >| way.
    |     | >|
    |     | >| Since I failed to set up a server which has the same problem on
    my
    |     | >| own machine, I would be *VERY* thankful if you could give tracing
    the
    |     | >| problem at least a quick shot.
    |     | >|
    |     | >| For now, we'll just not send any Accept-Encoding: header at all,
    but,
    |     | >| according to rfc2616, then "the server MAY assume that the client
    will
    |     | >| accept any content coding." which is not what I want.
    |     | >|
    |     | >| I know that you are not responsible or authoritative for any
    flaws in
    |     | >| PHP or apache, but as you seem to have experience with a major
    project
    |     | >| in PHP, *and* run a site that is affected by the problem, I hope
    I
    |     might
    |     | >| raise your interest in the question.
    |     | >|
    |     | >| Your feedback will be very much appreciated.
    |     | >|
    |     | >| Best regards,
    |     | >| --Andreas
    |     | >|
    |     | >|
    |     | >|
    |     | >
    |     | >
    |     | >--
    |     | >PHP Development Mailing List <http://www.php.net/>
    |     | >To unsubscribe, visit: http://www.php.net/unsub.php
    |     |
    |     |
    |
    |
    |     --
    |     PHP Development Mailing List <http://www.php.net/>
    |     To unsubscribe, visit: http://www.php.net/unsub.php
    |
    |
    |
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php


« previous php.dev (#87338) next »