httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <DRugg...@primary.net>
Subject Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c
Date Thu, 26 Jan 2017 00:18:12 GMT
To clarify, the issues with handling of the buckets and the fact that
buckets are not being set aside came from the original code. The
question about what to do regarding f->next versus passing the data
along some other way is the only one that came from the code I added to
make the header optional.

Being honest, I don't fully grok all the details of the filter stack and
what kinds of buckets to expect emanating from core as the request for
data propagates up through the input filters, but what Rudiger has
pointed out seems like a structural problem with the module that could
bite users under certain circumstances. What I'm particularly unclear
about is what those circumstances would be.

I'll try to reply to the other thread to provide more clarity.

-- 
Daniel Ruggeri

On 1/24/2017 8:36 AM, Jim Jagielski wrote:
> ++1. I know that Daniel is out of pocket for a little bit so I'l
> give it a coupla more days before I "restore" to the original filter
> code...
>> On Jan 24, 2017, at 3:46 AM, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>
>>
>> On 01/17/2017 02:48 PM, Jim Jagielski wrote:
>>>> On Jan 16, 2017, at 6:57 PM, Daniel Ruggeri <DRuggeri@primary.net>
wrote:
>>>>
>>>> For the most part, yes except the portions that make the header presence
>>>> optional (the HDR_MISSING case). Those were added as it came into the
>>>> code base to handle a use case I was working on. I've added some
>>>> comments inline since I won't have time to poke around myself for a
>>>> while yet.
>>>>
>>>>
>>>> For convenience, here's a link to the original code
>>>>
>>>> https://github.com/roadrunner2/mod-proxy-protocol/blob/master/mod_proxy_protocol.c
>>>>
>>> Would it make sense to have the "stable" version available
>>> for backport, and keep in the WIP in trunk?
>>>
>> This would be an option, but apart from this I would like to see the WIP in trunk
>> somehow fixed. Otherwise it is a perfect candidate for falling through the cracks
>> and giving yet another surprise once we branch "whatever we name it" from trunk.
>> IMHO easier to fix that now or even revert that part for the time being while people
>> remember what is going on then later digging through it while hitting the issues.
>>
>> Regards
>>
>> RĂ¼diger


Mime
View raw message