Should have read the whole message...
Sent to bugzilla-ad...@apache.org
CJ
Le 01/07/2015 07:08, Christophe JAILLET a écrit :
Hi,
I wanted to CLOSE bug #57992 and #57993 as INVALID.
Strangely, they apparently have never been sent to
b...@httpd.apache.org (at least according to the mail archiv
Hi,
I wanted to CLOSE bug #57992 and #57993 as INVALID.
Strangely, they apparently have never been sent to b...@httpd.apache.org
(at least according to the mail archive I use)
Moreover, when I try to CLOSE them, I get an error, even if the state is
correctly changed.
I don't really know who
On Tue, Jun 30, 2015 at 5:29 PM, Graham Leggett wrote:
> To be 100% safe, send the flush bucket down the stack on it’s own, not tacked
> onto the end of the brigade with the EOS.
Thanks all -- I lucked into having that relationship already between
the heap buckets and EOS, and the flushes are ju
On 30 Jun 2015, at 8:53 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>> This turned into a bot of a pain when I realized just using a flush
>> bucket accomplishes the same thing (everything up to the flush bucket
>> is blocking)
>
> Are you sure that works with every filter in between? As far as I
On Tue, Jun 30, 2015 at 8:53 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: Eric Covener [mailto:cove...@gmail.com]
>> Gesendet: Dienstag, 30. Juni 2015 20:09
>> An: Apache HTTP Server Development List
>> Betreff: Re: option to block async write completio
> -Ursprüngliche Nachricht-
> Von: Eric Covener [mailto:cove...@gmail.com]
> Gesendet: Dienstag, 30. Juni 2015 20:09
> An: Apache HTTP Server Development List
> Betreff: Re: option to block async write completion?
>
> On Fri, Jun 19, 2015 at 10:03 AM, Eric Covener
> wrote:
> >> Maybe ma
On Fri, Jun 19, 2015 at 10:03 AM, Eric Covener wrote:
>> Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case?
>
> that's interesting, will check it out.
This turned into a bot of a pain when I realized just using a flush
bucket accomplishes the same thing (everything up to the
This is the case, a single SubstituteInheritBefore directive,
defaulting to Off in trunk and On in 2.4 / 2.2 (proposed patches).
On Tue, Jun 30, 2015 at 12:39 PM, Plüm, Rüdiger, Vodafone Group
wrote:
> +1. They can even make their configuration "future proof" today by setting
> the 2.4 default b
On Tue, Jun 30, 2015 at 3:35 AM, William A Rowe Jr wrote:
> On Mon, Jun 29, 2015 at 8:06 PM, Yann Ylavic wrote:
>>
>> Maybe defining (naming) inherit_before tristate values would help:
>
>
> Not really...
>
>> +a->inherit_before = (over->inherit_before == INHERIT_ON
>> +
+1. They can even make their configuration "future proof" today by setting the
2.4 default behaviour explicitly.
Regards
Rüdiger
> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Dienstag, 30. Juni 2015 12:25
> To: dev@httpd.apache.org
> Cc: c...@httpd.apache.
My goal is that all outstanding bugs and backports and/or showstoppers
have sufficient +1 and sufficient testing to warrant a T&R next
week (ie: the week of July 7th)
My pref is that we create one single directive which controls
this. With 2.4 the default is the "old" (incorrect) merge and
with trunk it is the new (correct) merge. That way those
upgrading from 2.4 -> 2.6/3.0 will only need to worry about
a directive default change.
* William A Rowe Jr wrote:
> On Mon, Jun 22, 2015 at 2:01 PM, André Malo wrote:
> > * Yann Ylavic wrote:
> > > It seems that RedirectMatch isn't documented without the third (URL)
> > > argument, unless in .
> >
> > Huh? Actually it is (or maybe I'm not getting something here). I checked
> > at l
Thanks for reporting this before the testing/release.
Fixed in r1688274 (will now propose a backport), and since this is a
showstopper, it will be merged (once reviewed) before 2.4.16/2.2.30.
Proposed patch (for backport) is
http://people.apache.org/~ylavic/httpd-2.4.x-fix_LimitRequestBody.patch
14 matches
Mail list logo
