httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r551171 - /httpd/httpd/branches/2.2.x/STATUS
Date Wed, 27 Jun 2007 17:25:00 GMT

On Jun 27, 2007, at 12:20 PM, Ruediger Pluem wrote:

>
>
> On 06/27/2007 05:51 PM, Jim Jagielski wrote:
>>
>> On Jun 27, 2007, at 11:08 AM, Nick Kew wrote:
>>
>>> On Wed, 27 Jun 2007 14:17:36 -0000
>>> jfclere@apache.org wrote:
>>>
>>>> +    * mod_proxy: Arrange the timeout handling.
>>>> +      Trunk version of patch:
>>>> +        http://svn.apache.org/viewvc?view=rev&revision=550514
>>>> +        http://svn.apache.org/viewvc?view=rev&revision=546128
>>>> +      +1: jfclere
>>>
>>> Looks reasonable, but is there a reference to the problem it solves?
>>>
>>>> +
>>>> +    * mod_proxy: Improve traces in  
>>>> ap_proxy_http_process_response()
>>>> +      to investigate PR37770.
>>>> +      Trunk version of patch:
>>>> +        http://svn.apache.org/viewvc?view=rev&rev=549420
>>>> +      +1: jfclere
>>>
>>> Hmmm.  This is designed to improve an error message?
>>>
>>> +    tmp_bb = apr_brigade_create(r->pool, r->connection- 
>>> >bucket_alloc);
>>> +    rv = ap_rgetline(&tmp_s, n, &len, r, fold, tmp_bb);
>>> +    apr_brigade_destroy(tmp_bb);
>>>
>>> Isn't a whole new brigade an unnecessarily overhead (and
>>> potentially large if the function gets used more in future)?
>>> What problem does it solve?
>>>
>>
>> Yeah... all this just so we can see the return val
>> of ap_rgetline()??
>
> Yes, but have a look at ap_getline in protocol.c which was used  
> before instead
> of ap_proxygetline. It does exactly the same thing regarding the  
> brigade.

I wasn't concerned about the brigade, but rather the extra
layer of complexity just so we see a return value...
Is it worth it?


Mime
View raw message