Actually, that was in APR-util 1.6.1, see the APR release announcement
and Craig's
users@httpd post.
On Wed, Oct 25, 2017 at 4:02 PM, Craig Young wrote:
> I’m not sure if this is what is referred to in the Apache 2.4.29
> announcement, but please note that the Apache Portable Runtime v1.6.3 re
Hi Ruediger,
the following patch (still to be carefully tested and/or improved) should
force RewriteCond to behave like an block adding the Vary header
simply if the condition is evaluated (so header value present in the
request but not satisfying the condition or header completely absent):
http
To be clear: "delete" simply means "no longer seen in HEAD". This is
version control. The data cannot truly be deleted, so it can always be
revived. Or reviewed.
On Oct 25, 2017 12:31, "Marion & Christophe JAILLET" <
christophe.jail...@wanadoo.fr> wrote:
> Just to mention that before giving a +1,
Just to mention that before giving a +1, I made a copy of these
repositories in order to dig later on, in order to see if something
useful seems to be there.
Don't have that much time these days to play with httpd, but will do and
will report anything that looks valuable.
CJ
Le 25/10/2017 à
On 10/25/2017 06:23 PM, Reindl Harald wrote:
> it is *not* helpful when you already have deployed httpd 2.4.29 that you
> by random luck face a apr-1.6.3 build on the fedora buildserver
I'd suggest you post this to d...@apr.apache.org if you want them to
update their dist page.
With regards,
Dani
it is *not* helpful when you already have deployed httpd 2.4.29 that you
by random luck face a apr-1.6.3 build on the fedora buildserver
(https://koji.fedoraproject.org/koji/buildinfo?buildID=989222) either
this stuff on top should be removed completly or properly updated, if
it's not there at
Are there anything of "value" in any of those branches?
If not, prune away!
> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr wrote:
>
> On Tue, Oct 24, 2017 at 3:28 AM, Steffen wrote:
>>
>> On Tuesday 24/10/2017 at 10:26, Steffen wrote:
>>
>> Can someone clean up the not needed anymore back
> On Oct 24, 2017, at 10:20 PM, Jacob Champion wrote:
>
> On 10/24/2017 11:45 AM, William A Rowe Jr wrote:
>> On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski wrote:
>>> That is way when we backport we transition to RTC, because
>>> we want to ENSURE it's been reviewed.
>> Wrong. I was there. RT
> On Oct 25, 2017, at 7:48 AM, Eric Covener wrote:
>
>> The guidelines are fine with me and seem to make sense to get to an API
>> stable next GA. It is good to have a list of 'To Do's' that needs to be done
>> before next GA. That helps people looking for interesting and useful work to
>> spen
The only reasons we keep those factors as ints rather than floats are:
1. We can't change the struct fields in 2.4.x
2. The rationale that int based operations will "always"
be faster than floating point
2.5.0 doesn't suffer from #1. We can break API/ABI if there's
a good reason. And #2
> The guidelines are fine with me and seem to make sense to get to an API
> stable next GA. It is good to have a list of 'To Do's' that needs to be done
> before next GA. That helps people looking for interesting and useful work to
> spend their time :-).
> Once it is decided that the API is stabl
> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 24. Oktober 2017 19:00
> An: httpd
> Betreff: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines
>
> I'd like to propose the following, so we can decide on what course to
> chart b
On Tue, Oct 24, 2017 at 11:58 PM, Jim Jagielski wrote:
> As you said, the external representation as a float is syntactic sugar.
> But the patch breaks that. Someone enters in, for example, 2.50
> and what's displayed in 250, instead of 2.50.
>
> Since all this is normalized by how ldfactor is USE
Am 24.10.2017 um 23:05 schrieb William A Rowe Jr:
On Tue, Oct 24, 2017 at 8:11 AM, William A Rowe Jr wrote:
On Tue, Oct 24, 2017 at 3:28 AM, Steffen wrote:
On Tuesday 24/10/2017 at 10:26, Steffen wrote:
Can someone clean up the not needed anymore backports/branches
http://svn.apache.org/
14 matches
Mail list logo