On Mon, Jun 4, 2018 at 7:23 PM, Paul Callahan wrote:
>
> I did try with input filters. The reason I'm trying to do this in a
> handler is because I want to return 403 to the browser if the request body
> has something unsavory in it. With reverse proxied requests, it appears
> the input filter
On Mon, 4 Jun 2018 10:23:59 -0700
Paul Callahan wrote:
> Thank you for your replies.
>
> I did try with input filters. The reason I'm trying to do this in a
> handler is because I want to return 403 to the browser if the request
> body has something unsavory in it. With reverse proxied
Thank you for your replies.
I did try with input filters. The reason I'm trying to do this in a
handler is because I want to return 403 to the browser if the request body
has something unsavory in it. With reverse proxied requests, it appears
the input filter fires too late and if I try to
Hi Yann!
2018-06-04 15:59 GMT+02:00 Yann Ylavic :
> Hi Luca,
>
> On Mon, Jun 4, 2018 at 11:23 AM, Luca Toscano
> wrote:
> >
> > To keep archives happy: opened
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=62362 and added a patch
> in
> > there, if anybody wants to review it and give me
Thanks for the review! I will take this and clean up the code, mod_ssl
certainly deserves it.
> Am 23.05.2018 um 09:51 schrieb Joe Orton :
>
> Easier to do here than dump in STATUS; looking at reviewing the 2.4.x
> backport:
>
>
Hi Luca,
On Mon, Jun 4, 2018 at 11:23 AM, Luca Toscano wrote:
>
> To keep archives happy: opened
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62362 and added a patch in
> there, if anybody wants to review it and give me suggestions I'd be happy :)
The semantic of tmpbb is not very clear in
2018-05-04 14:46 GMT+02:00 Luca Toscano :
> Hi everybody,
>
> as part of the plan to add more documentation about httpd's internals I am
> trying to debug more tricky bugs (at least for me) reported by our users,
> in order for example to better understand how the filters chain works in
> depth.
You see correctly.
> Am 04.06.2018 um 11:13 schrieb Steffen :
>
> After the push from svn to github:
>
> I see that version svn is 1.10.20 and github 1.10.21-git
>
>
> On Monday 04/06/2018 at 10:37, Stefan Eissing wrote:
>> I was not reading my mail in the last days, but you happily
>>
After the push from svn to github:
I see that version svn is 1.10.20 and github 1.10.21-git
On Monday 04/06/2018 at 10:37, Stefan Eissing wrote:
I was not reading my mail in the last days, but you happily
opened a github issue for this since I did not answer your
question for 24 hours.
> On 4 Jun 2018, at 08:55, Sorin Manolache wrote:
>
> On 2018-06-04 08:27, Paul Callahan wrote:
>> In apache modules, my understanding is if a handler declines a request, the
>> request is passed on to the next suitable handler. I'm finding though if
>> I read the bucket_brigade/request
I was not reading my mail in the last days, but you happily
opened a github issue for this since I did not answer your
question for 24 hours. That is good thinking.
I hope I answered the ticket to your satisfaction. I also
pushed the changes from Apache subversion to github that
had not arrived
On 2018-06-04 08:27, Paul Callahan wrote:
In apache modules, my understanding is if a handler declines a request, the
request is passed on to the next suitable handler. I'm finding though if
I read the bucket_brigade/request body, and then decline the request, the
subsequent handler doesn't
In apache modules, my understanding is if a handler declines a request, the
request is passed on to the next suitable handler. I'm finding though if
I read the bucket_brigade/request body, and then decline the request, the
subsequent handler doesn't get any data. It is like the act of reading
13 matches
Mail list logo
