Re: [users@httpd] RE: [ANNOUNCE] Apache HTTP Server 2.4.29 Released

[William A Rowe Jr]

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 release 
> resolved memory safety issues I found in functions used within HTTP server.  
> This was released in conjunction with 2.4.29.
>
> Using HTTP server linked to prior versions of APR exposes the risks outlined 
> in my email sent to this list on Monday.
>
> Best Regards,
> Craig
>
> On 10/25/17, 1:05 PM, "Development Manager" 
>  wrote:
>
> The 2.4.29 changes document doesn't reference any CVE articles, though 
> the announcement indicates that this is a security release. Are any of the 
> 2.4.29 changes security related?
>
> Thanks,
> Jim
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>

Re: mod_rewrite, vary headers and internal redirects

[Luca Toscano]

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://home.apache.org/~elukey/httpd-trunk-mod_rewrite-add_vary_header_always.patch

It seems to be a big change in behavior though, I'd be curious to find out
the motivations of the implementation choice at the time (will try to dig a
bit into svn history).

Thanks!

Luca

2017-10-23 8:43 GMT+02:00 Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com>:

> I would tend to say that the  code is correct and the RewriteCond code
> is wrong, because it doesn’t matter if the condition becomes true or false.
> The headers value has an influence on the result. Tricky question is what
> to do regarding Vary if the non-presence of a header has an influence.
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* Luca Toscano [mailto:toscano.l...@gmail.com]
> *Gesendet:* Sonntag, 22. Oktober 2017 11:47
> *An:* Apache HTTP Server Development List 
> *Betreff:* Re: mod_rewrite, vary headers and internal redirects
>
>
>
> Hi everybody,
>
>
>
> 2017-10-09 13:46 GMT+02:00 Luca Toscano :
>
> Hi Yann,
>
>
>
> 2017-10-08 14:13 GMT+02:00 Yann Ylavic :
>
> On Sun, Oct 8, 2017 at 2:03 PM, Yann Ylavic  wrote:
> > Hi Luca,
> >
> > On Sun, Oct 8, 2017 at 11:59 AM, Luca Toscano 
> wrote:
> >>
> >> Does this approach make sense? Is there any smarter way to do it?
> >
> > I can't tell that I love the hack in internal redirects but looks like
> > a simple way to handle the case...
> > Nit: maybe a more descriptive name for the "keep-vary-header" note,
> > "redirect-keeps-vary"?
>
>
>
> +1
>
>
>
>
> But after all, if we reach an internal redirect with some Vary header
> already set, maybe we should never drop it, thus internal redirects
> should preserve Vary in any case...
>
>
>
> I'd prefer to limit the scope of the httpd configurations affected by this
> change to the minimum, but the change would probably look less hacky :)
>
>
>
>
>
> After https://svn.apache.org/r1811744 trunk should be inline with what
> the docs say, but I have another question now: a RewriteCond condition
> (containing something like HTTP:someheader) adds a Vary header to the
> response only if the condition evaluates to true, meanwhile a 
> condition adds the Vary header regardless. Is there any good motivation for
> this difference or they should be modified to be more consistent? The 
> block behavior seems to be more sound (after reading
> https://tools.ietf.org/html/rfc7231#section-7.1.4), but I'd like to hear
> more expert opinions :)
>
>
>
> Thanks!
>
>
>
> Luca
>

Re: Pruning working branches (Was: Re: Why?)

[Greg Stein]

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, 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 à 14:29, Jim Jagielski a écrit :
>
>> 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  backports/branches
 http://svn.apache.org/viewvc/httpd/httpd/branches/

 httpd 2.4.1 was tagged at r1243503.
>>>
>>> I'd propose we start by pruning all working branches not updated since
>>> this tag.
>>>
>>> Thoughts?
>>>
>>
>>
>

Re: apr "the latest available version"

[Daniel Gruno]

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,
Daniel.

> (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 all one would look at the filelist
> 
> https://www.apache.org/dist/apr/
> 
> Important Notices
>     Download from your nearest mirror site!
>     APR 1.6.2 is the latest available version
>     APR-util 1.6.0 is the latest available version
>     APR-iconv 1.2.1 is the latest available version
> 
> APR 1.6.2 is the latest available version
> 
> APR 1.6.2 has been released, and should be considered "general
> availability".
> APR-util 1.6.0 is the latest available version
> 
> APR-util 1.6.0 has been released, and should be considered "general
> availability".

apr "the latest available version"

[Reindl Harald]

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 all one would look at the filelist


https://www.apache.org/dist/apr/

Important Notices
Download from your nearest mirror site!
APR 1.6.2 is the latest available version
APR-util 1.6.0 is the latest available version
APR-iconv 1.2.1 is the latest available version

APR 1.6.2 is the latest available version

APR 1.6.2 has been released, and should be considered "general 
availability".

APR-util 1.6.0 is the latest available version

APR-util 1.6.0 has been released, and should be considered "general 
availability".

Re: Pruning working branches (Was: Re: Why?)

[Jim Jagielski]

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  backports/branches
>> http://svn.apache.org/viewvc/httpd/httpd/branches/
>> 
> 
> httpd 2.4.1 was tagged at r1243503.
> 
> I'd propose we start by pruning all working branches not updated since this 
> tag.
> 
> Thoughts?

Re: Thoughts on 2.5.0

[Jim Jagielski]

> 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. RTC was adopted in order to ensure both the
>> reliability but moreso, the compatibility of changes during a given
>> x.y major/minor release cycle. CTR existed to make forward progress
>> and get out of our developers' way.
> 
> I'm not really sure Jim's statement here is "wrong". Regardless of historical 
> context. We use RTC when we want to guarantee review.
> 
>> You are suggesting a change of policy. It
>> is not policy to use RTC to get from trunk to 2.6.0, and will not
>> become policy without a vote for such a change by the PMC.
> 
> I'm not entirely convinced Jim is suggesting a change in policy, as you say. 
> But in any case, I would be +1 to such a change. We should not be releasing a 
> 2.6.x that contains unreviewed code.
> 

It's not a policy change, right. It's a clarification of the policy. CTR was to
allow for fast development. As Bill said, so the process got out of
the developers way. But we also ensured RTC such that anything
that made its way *into a release branch* was "formally" reviewed.

Thx!

Re: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Jim Jagielski]

> 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 
>> spend their time :-).
>> Once it is decided that the API is stable I guess we need
>> to branch in order to avoid restraining further progress on trunk by 
>> developers
>> that want to change the API further in an incompatible way. This could still 
>> be a '2.5.x' branch
>> that morphs into a 2.6.x or 3.0.x branch later.
>> 
>> My personal itch and use of my regrettably very limited amount of time these 
>> days is
>> on the current 2.4 and getting at least some of the features back into it
>> (a little bit like Jim's approach). This has to do with my dayjob where it 
>> is much easier
>> to upgrade to 2.4.next than to a new GA version.
>> But I see merit in getting more track on moving forward with current trunk 
>> to something
>> releasable. So go for the alpha tags and see if you get sufficient votes for 
>> it and what
>> the feedback of the broader community is. If it is valuable: Great. If not
>> or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
>> just stop
>> due to lack of interest in the community.
> 
> +1

Same here. +1!

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

[Jim Jagielski]

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 is open for debate :)

But yes, the extra granularity (dynamic range) of ldfactor
now means it may take longer to reach steady state for
some methods. We could use the 'age' method to maybe adjust
for that...

Re: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Eric Covener]

> 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 stable I guess we need
> to branch in order to avoid restraining further progress on trunk by 
> developers
> that want to change the API further in an incompatible way. This could still 
> be a '2.5.x' branch
> that morphs into a 2.6.x or 3.0.x branch later.
>
> My personal itch and use of my regrettably very limited amount of time these 
> days is
> on the current 2.4 and getting at least some of the features back into it
> (a little bit like Jim's approach). This has to do with my dayjob where it is 
> much easier
> to upgrade to 2.4.next than to a new GA version.
> But I see merit in getting more track on moving forward with current trunk to 
> something
> releasable. So go for the alpha tags and see if you get sufficient votes for 
> it and what
> the feedback of the broader community is. If it is valuable: Great. If not
> or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
> just stop
> due to lack of interest in the community.

+1

AW: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Plüm , Rüdiger , Vodafone Group]

> -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 between here and there.
> 
> Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release.
> Through a series of non-GA releases, 2.5.x is eventually approved to
> become the next 'evens' GA release. What we number that by default is
> 2.6.0, or if the group decides the changes are significant enough,
> 3.0.0.
> 
> What I propose now is that we designate all 2.5.x releases as -alpha
> *until the list decides the API (not ABI) changes are complete*.
> That's the only process change.
> 
> We track this through STATUS, with a vote to promote API-changing
> proposals to SHOWSTOPPERs to -beta. So developers will be aware when
> we declare -beta that we will no longer change the API for them, and
> their modules must conform to the new API, barring any radical
> discoveries that prevent us from shipping that API (which might then
> return us to the -alpha phase.)
> 
> E.g. we had a security@ discussion about changing the handling of URI
> significantly so that the meaning of escaped vs. unescaped characters
> is never obtuse. There are several proposals on that table (embargoed
> at that time waiting for our HTTP protocol correctness patches to be
> published.) Those need to come here to dev@. One of them will land in
> STATUS, and will inevitably be upvoted to SHOWSTOPPER status;
> 2.5.x-beta shouldn't happen, IMO, until some code and structure
> changes to accomplish this has been accepted.
> 
> Because it is CTR, we don't need STATUS for patch voting, but I do
> think we want STATUS to identify what is the minimum changes needed to
> declare the next API/ABI-breaking release complete and ready for
> -beta.
> 
> Thoughts?

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 stable I guess we need
to branch in order to avoid restraining further progress on trunk by developers
that want to change the API further in an incompatible way. This could still be 
a '2.5.x' branch
that morphs into a 2.6.x or 3.0.x branch later.

My personal itch and use of my regrettably very limited amount of time these 
days is
on the current 2.4 and getting at least some of the features back into it
(a little bit like Jim's approach). This has to do with my dayjob where it is 
much easier
to upgrade to 2.4.next than to a new GA version.
But I see merit in getting more track on moving forward with current trunk to 
something
releasable. So go for the alpha tags and see if you get sufficient votes for it 
and what
the feedback of the broader community is. If it is valuable: Great. If not
or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
just stop
due to lack of interest in the community.


Regards

Rüdiger

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

[Yann Ylavic]

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 USED, the algos
> still work, but are now more granular, which is what we wanted.

OK, fair enough (my change was a bad idea).
I'll revert, thanks for the review.

Re: Pruning working branches (Was: Re: Why?)

[Rainer Jung]

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/viewvc/httpd/httpd/branches/



httpd 2.4.1 was tagged at r1243503.

I'd propose we start by pruning all working branches not updated since this tag.

Thoughts?


To clarify; this list consists of;

Last rev – Last modified – Branch

  371484  11 years  async-read-dev/
  367678  11 years  authz-dev/
  446636  11 years  cache-refactor/
  369019  11 years  execd-dev/
  393955  11 years  fcgi-proxy-dev/
  8095458 years  httpd-2.2-proxy/
  431328  11 years  httpd-proxy-scoreboard/
  1200612  5 years  input-filter-dev/
  171035  12 years  listen-protocol/
  151147  12 years  proxy-reqbody/
  1150173  6 years  revert-ap-ldap/
  7236558 years  wombat-integration/


+1, prune.

Rainer

Re: Pruning working branches (Was: Re: Why?)

[Marion & Christophe JAILLET]

+1


Le 24/10/2017 à 23:05, William A Rowe Jr a écrit :

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/viewvc/httpd/httpd/branches/


httpd 2.4.1 was tagged at r1243503.

I'd propose we start by pruning all working branches not updated since this tag.

Thoughts?

To clarify; this list consists of;

Last rev – Last modified – Branch

  371484  11 years  async-read-dev/
  367678  11 years  authz-dev/
  446636  11 years  cache-refactor/
  369019  11 years  execd-dev/
  393955  11 years  fcgi-proxy-dev/
  8095458 years  httpd-2.2-proxy/
  431328  11 years  httpd-proxy-scoreboard/
  1200612  5 years  input-filter-dev/
  171035  12 years  listen-protocol/
  151147  12 years  proxy-reqbody/
  1150173  6 years  revert-ap-ldap/
  7236558 years  wombat-integration/