gmane.comp.apache.devel

Re: Time for 2.4.5 ??

Gregg Smith — 2013-05-25T05:05:23

I'm +1 to this approach.

Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))

Gregg Smith — 2013-05-25T04:55:43

Vice-versa, I never have a problem with release builds which probably 
explains why I do so few debug builds.

It ends up being all objects land in /Release but then the linker looks 
in /Debug for them.

libhttpd is the culpret here for me, I do not think I have had the 
problem with anything else. It's now been two or three weeks since I 
fought the dreaded debug build so who knows as I have done too many 
release builds since :)  But libhttpd stands out above all and I have no 
idea why it's happening on this project, I'm just not seeing it.

Gregg

Re: Time for 2.4.5 ??

Guenter Knauf — 2013-05-25T03:46:56

Hi Daniel,
On 25.05.2013 02:06, Guenter Knauf wrote:
done.

Found another small docu bug:

r:unescape(string) -- Unescapes an URL-escaped string:

local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5"
local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5'

the function call should here be r:unescape(url) ...

Gün.

suexec and reload modules

Nick Edwards — 2013-05-25T03:10:24

Hi,

Two questions

First, when apache gracefully reloads, it does not reload the modules?
is there an option to have it fully reloads them? or, is an option
planned?

Case: We use mod cband to control clients speed and limits, but if we
alter their configuration to increase the speed, reload does not
change it, only a full stop, and start changes. So pewrhaps a feature
request?

Second, SuExec, is there plan to modify suexec so docroot build option
is the absolute root of what can be accessed, similar to using
php_admin_value open_basedir  which locks down (yes I know it does its
best but rogue modules may break out of this) so users can not
traverse parent directories.

If apache/php can do its best to lock down php with no noticable
resource impact, can not understand why the main programme, apache,
can not either - without creating the nightmare that is jails, or
relying on third party modules like mod security, which have had
problems of their own, and even some configurations, like ours, mod
security is not by their own worlds, suited to our needs.

I know suexec hardens things up a little, and stops,. or at least
tracks who is being naughty, but, prevention is better than the cure.

Re: Time for 2.4.5 ??

Guenter Knauf — 2013-05-25T00:06:00

Hi Daniel,
On 24.05.2013 23:45, Daniel Gruno wrote:
great!

hehe, ok; I look into it soon.

yes, see the apr_dbm.h header; SDBM is the only database we allways have 
even without any driver or external libs; it can be used f.e. for 
password storage (htdbm.c), and I think mod_dav makes use of it for its 
lock database; as usage example might serve mod_authn_dbm.c ...

Gün.

Re: Time for 2.4.5 ??

Daniel Gruno — 2013-05-24T21:45:30

I can only say +1 from me, we need consistency here :)

further more I believe r.sleep() would be better renamed to

That's fine by me, I'm not married to 'sleep' (although I do like a good
nap)

I've not looked in APR, but I assume this is something supported in
there? Perhaps if you could come up with a sketch/mock api, we could get
started on this?


I ran into some issues with MSVC10/11, but they appear to have been
fixed (though not 100% sure) - but I'm not a big Windows expert anymore :|

 I think we should now copy over the complete trunk code to

With regards,
Daniel.

Re: Time for 2.4.5 ??

Guenter Knauf — 2013-05-24T21:03:02

ATM I think this is not needed - from what I tested during past weeks 
the current trunk code is at least as good / bad as what is already in 
2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me 
due to various bug fixes beside the added new stuff.

Gün.

Re: Time for 2.4.5 ??

Graham Leggett — 2013-05-24T20:51:17


Pretty much all of the cache and proxy related proposals are fixes for RFC violations, detected courtesy of the CoAdvisor test suite. It would be goodness to get these out there.

Regards,
Graham
--

Re: Time for 2.4.5 ??

William A. Rowe Jr. — 2013-05-24T20:22:42

On Wed, 22 May 2013 14:20:03 -0400
Jim Jagielski <jim< at >jaguNET.com> wrote:


What is your thought on RSN?  Sometime Thurs-Sat timeframe
late next week?  It could be good to have a goal and then
slip the whole thing 1 week exactly if we can't reach it.

My schedule is now very flexible, so you choose :)  I like
the late-week roll so that weekday coders and weekend warriors
can both put their hands on the candidate.

Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))

William A. Rowe Jr. — 2013-05-24T20:19:02

On Fri, 24 May 2013 21:53:50 +0200
Guenter Knauf <fuankg< at >apache.org> wrote:



The concensus seems to be forming around cmake, and it is certainly
my preference from working with pcre and other libraries and projects.

But in the walk-before-you-run department, it's probably best to swap
the scons for cmake over at the apr project, and that will take our
most significant obstacle out of the way.  The httpd cmake will still
be quite complex, but not obnoxiously so, and our apr experience would
be beneficial to setting out a well thought out plan.

Re: Whither Windows (Was: Re: Intent to revert commit r1332643)

William A. Rowe Jr. — 2013-05-24T20:16:42

On Fri, 24 May 2013 12:43:23 -0700
Ben Reser <ben< at >reser.org> wrote:


As far as we are aware, no commercial distributions and so far,
no released free stable distributions incorporate 2.4.  A couple
have started integrating it, but the single biggest obstacle that
is reported by the packagers community is that mod_perl had not yet
supported 2.4 and that is an important package dependency to them.

Re: Time for 2.4.5 ??

William A. Rowe Jr. — 2013-05-24T20:14:02

On Fri, 24 May 2013 21:02:04 +0200
Guenter Knauf <fuankg< at >apache.org> wrote:

There are several others of us, but large patch sets are difficult 
to incorporate in our day-to-day build trees.  What about a sandbox
of all of the proposed deltas, either just the modules/lua/ branch
or the entire tree if that isn't realistic.  It's preferable to just
svn switch that branch to the sandbox for some more active eyeballs
looking at the thing.

Re: httpd buildbot

William A. Rowe Jr. — 2013-05-24T20:11:40

On Fri, 24 May 2013 21:42:58 +0200
Guenter Knauf <fuankg< at >apache.org> wrote:


We could do both... should be straightforward.

Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))

Guenter Knauf — 2013-05-24T19:53:50

yeah ...; and from what I see our project files are already broken even 
when not converted and used directly with MSVC6, f.e. when doing a 
release build a bunch of files land in the debug folder, and finally at 
linking stage it breaks ...
probably we should think about moving either to plain Nmakefiles (as 
Pierre Joy also suggested), or add a Cmake build system; for me SCon is 
no alternative since I saw it too often already fail on modern Linux 
boxes (with other projects), so I have no hope that it works any better 
on Windows ...

and regarding trunk: AFAICT there are no improvements (what I mentioned 
above was with trunk) ...

Gün.

httpd buildbot

Guenter Knauf — 2013-05-24T19:42:58

I dont know who has access / maintains the httpd buildbot, but I would 
like to have it build with maintainer mode; this could be useful to 
avoid that code we dont want slips in, f.e. var declarations after 
statements ...

Gün.

Re: Whither Windows (Was: Re: Intent to revert commit r1332643)

Ben Reser — 2013-05-24T19:43:23

On Fri, May 24, 2013 at 8:23 AM, William A. Rowe Jr.
<wrowe< at >rowe-clan.net> wrote:

Can't speak to this, it's not important to my use since I avoid the
case sensitivity issues on OS X.

I've had no problems building httpd on OS/X on 10.7 (I haven't
bothered to upgrade to 10.8).  I do a fair amount of work on OS X
directly and often build httpd-trunk and releases with debugging.
There may be computability issues like you pointed out above, but I
quite frankly have never noticed them.  Granted my use of httpd on OS
X is purely developmental and I likely wouldn't run into the types of
issues that someone using httpd for production servers on OS X would.


I've never bothered to try to download a httpd binary build, it's easy
enough to build that I don't feel the need.

10.7 still had httpd 2.2, not sure what 2.4 has.

Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))

Ben Reser — 2013-05-24T19:37:31

On Fri, May 24, 2013 at 8:13 AM, William A. Rowe Jr.
<wrowe< at >rowe-clan.net> wrote:

The build system should be able to compile with the major tool chains,
nobody expects to know how to work around weird autoconf, make, gcc,
etc quirks on Linux.  I don't say this to be dismissive of anyones
contributions but just to point out that producing Windows builds with
a modern toolchain is not simple.

I did a bunch of work on scripting building the dependencies for
Subversion on Windows that's located here:
http://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl

By far httpd was the biggest pain of any of the dependencies to get to work.

If your only interest is building httpd on Windows with Visual Studio
2012, taking a look at build_httpd() in that file should give a good
starting point.

Sometime when I find the time I want to fix the problems that I had to
work around the right way and not the hackish way I did in that script
and submit them back.  But I haven't gotten to it.

I'll admit that I haven't tried to build httpd-trunk on Windows so
maybe improvements have been made that haven't made their way over to
the 2.4 releases, Subversion certainly has similar issues with our 1.7
release branch.

Re: Whither Windows (Was: Re: Intent to revert commit r1332643)

Guenter Knauf — 2013-05-24T19:20:54

Hi Jim,
On 24.05.2013 14:52, Jim Jagielski wrote:
well, for me its no reason to just accept every code as long as it 
compiles on *nix platforms regardless of design flaws; also we could 
easily fix the stuff so that Windows would compile again even with the 
design flaw, but that's not what Bill would accept IIUC, and not what I 
would like to do ...

finally what I was mainly after was kicking on discussion again about 
how to fix it correctly, and thats now in progress ... ;-)

Gün.

Re: Time for 2.4.5 ??

Guenter Knauf — 2013-05-24T19:02:04

ok, after spending a bunch of hours during last weeks with testing 
mod_lua mainly on Windows I've finally removed my blocking vote from 
STATUS just now; nevertheless I feel that I did only test half of all 
the new stuff, and therefore my vote is +0.5 only ...
some things which I see as outstanding are:
- removal of the export declarations since they are unneeded (I will 
take a look into this during this weekend if nobody beats me)
- removal of some doubled code ( ap_lua_check_request_rec() )
- another docu fix for r:sleep() --> r.sleep(); meanwhile I have a 
stronger oppinion about this: I believe we should chage all functions to 
r:function() in order to separate them more clearly from vars like 
r.filename; further more I believe r.sleep() would be better renamed to 
r.usleep() taking microseconds instead of having a r.sleep() and then 
dealing with fractions of seconds - this way also the code would be 
cleaner and no calculation of the passed-in value needed anymore, just 
the value would get passed to apr_sleep().

Optional: I really would like to also have DBM support in addition to 
the DBD support, but unfortunately I had not the time yet to look into 
it ...

So how do we further proceed with mod_lua? There are certainly some 
remaining issues, but it just takes too long for only 2 persons to find 
them all; also I see with current code that it works fine when I compile 
it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not 
sure yet if this is an issue with MSVC9 itself, or with the converted 
projects ...; I think we should now copy over the complete trunk code to 
2.4.x branch, and keep the status 'experimental' so that users are 
warned that directives, functions, etc. might change even with an 
otherwise stable release branch;
hopefully then when more users play with mod_lua we will make faster 
progress with finding any further issues ...

also given that currently only Daniel and I (and Gregg with some 
testing) care about mod_lua I would like that we make an exception for 
this module so that we can backport any further modifications and fixes 
directly to the 2.4.x branch until we declare the module as stable and 
non-experimental.

Gün.

Re: Intent to revert commit r1332643

Guenter Knauf — 2013-05-24T17:21:11

Hi,
On 24.05.2013 14:57, Jeff Trawick wrote:
granted.

cool!

it was more an attempt by me to kick on discussion again; I feel 
sometimes that must be done in a drastical way when over one year 
nothing happend, and discussion just died ;-)
so that was kinda last resort - of course if com0ilation breaks no 
longer all is fine again!

Gün.

Re: Whither Windows (Was: Re: Intent to revert commit r1332643)

William A. Rowe Jr. — 2013-05-24T15:23:35

On Fri, 24 May 2013 08:52:05 -0400
Jim Jagielski <jim< at >jaguNET.com> wrote:


Thanks you just reminded me...

Another question is where exactly do we stand with OS/X right now?

Apple HFS+ is still not supported, there exists a forced lower-case
canonicalization hack authored by Apple, but AFAICT still no progress
on retrieving the true name of a file on a case-insensitive OS/X
volume which I suspect are still in common use on most OS/X boxen.
Of course, all the BSD-based file systems are strict case sensitive
and don't have security bypass issues when running 'vanilla' httpd.

Unfortunately I don't run an OS/X box anymore so it's awfully hard
for me to complete research on such a fix (and isn't so personally
interesting since my ppc laptop was retired for lack of OS updates).

Also wondering where the OS/X download lives?  It will build on any
OS/X box with a deployed toolchain, but I imagine many OS/X users
don't install that toolchain and live with the Apple provided
flavors, and would guess that 2.4.x is not part of that Apple OS
distributions so far.