Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: svn commit: r1773865 -
 /httpd/httpd/trunk/modules/http/http_filters.c
To: dev@httpd.apache.org
References: <20161212203144.CA4913A098C@svn01-us-west.apache.org>
 <65d0d395-a2ef-21fb-e3c3-7bea2aee6abd@gmail.com>
 <CAKQ1sVNWq9AphFHQ4uhSNnUBgVqSzuEAfAGqUTZFzGt6GoYuuw@mail.gmail.com>
 <76755976-6dc0-7a5a-1c0e-02ae6537fa7e@gmail.com>
 <AB1691BE05AE7F4992697F2A0835627AE7B8A978@VOEXM10W.internal.vodafone.com>
 <CAKQ1sVN2dsL=mSaV8EPoOacEjh=_++yJVstsBw4d854=yNm2Ag@mail.gmail.com>
 <58504E0D.8060002@apache.org>
 <6e14fa8c-21a5-3994-ac0b-58645506ba67@gmail.com>
From: Ruediger Pluem <rpluem@apache.org>
Message-ID: <585057B2.1000205@apache.org>
Date: Tue, 13 Dec 2016 21:18:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:43.0) Gecko/20100101
 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <6e14fa8c-21a5-3994-ac0b-58645506ba67@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
archived-at: Tue, 13 Dec 2016 20:19:02 -0000


On 12/13/2016 08:57 PM, Jacob Champion wrote:
> On 12/13/2016 11:37 AM, Ruediger Pluem wrote:
>> On 12/13/2016 02:49 PM, Yann Ylavic wrote:
>>> I don't find the change too complex after all, and that's a quite
>>> critical filter for doing the right/safe thing...
>>>
>>> I'm even inclined to do the below changes, so that we are really safe
>>> (i.e. ignore any data) after EOS...
>>
>> After this patch we do the wrong thing with an EOC bucket.
>> The current contract is that an EOC bucket *anywhere* in the brigade causes the
>> header filter to go out of the way. After the patch this is broken if
>> a bad header is present. But as EOC tells us to get out of the way and do nothing,
>> we don't need to take care about bad headers. This breaks edge case with mod_proxy_http
> 
> Can you elaborate on this broken case? Is it something we can add a test for?

Have a look at line 1334 of mod_proxy_http.c:

            /*
             * If we are a reverse proxy request shutdown the connection
             * WITHOUT ANY response to trigger a retry by the client
             * if allowed (as for idempotent requests).
             * BUT currently we should not do this if the request is the
             * first request on a keepalive connection as browsers like
             * seamonkey only display an empty page in this case and do
             * not do a retry. We should also not do this on a
             * connection which times out; instead handle as
             * we normally would handle timeouts
             */


Regards

Rüdiger