Re: Proposal: adoption of mod_combine subproject

[Jorge Schrauwen]

Looks like a very interesting module!

i'd love to see this adapted.

~Jorge


On Tue, Dec 13, 2011 at 7:27 PM, Graham Leggett  wrote:

> Hi all,
>
> As with mod_firehose and mod_policy, I have concluded negotiation with the
> BBC to open source some httpd modules that I wrote under the AL, and the
> BBC have very kindly agreed to donate the code to the ASF[1], which I
> believe would fit well as a subproject of httpd, and would like to know
> whether httpd would accept these.
>
> To be clear, this isn't a "code dump", my intention is to continue to
> develop and support this moving forward, and hopefully expand the community
> around them.
>
> - mod_combine: "Response concatenation"
>
> As a page gets more complex, and eventually parts of the page like the
> header and footer become maintained by separate teams, the elements that
> make up a page can become fragmented. In the process, you can end up with a
> page that takes ages to load, because lots of fragments of javascript or
> fragments of CSS files are being downloaded separately by the browser.
>
> mod_combine is a handler that allows multiple URLs hosted by the server to
> be concatenated together and delivered as a single response, cutting down
> on the number of requests, and in turn the page loading time.
>
> At the same time, mod_combine attempts to behave sensibly when one or more
> of the files is missing, so as not to amplify a failure. The handler also
> properly supports conditional requests, creating a "super ETag", and then
> reversing it to apply conditional requests on each element being
> concatenated.
>
> The code is currently packaged as an RPM, wrapped in autotools, and a
> snapshot is available here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_combine/
>
> The corresponding README documenting in more detail is here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_combine/README
>
> The code itself is here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_combine/mod_combine.c
>
> Obviously the expectation is for the documentation to be completed and
> fleshed out.
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322
>
> Regards,
> Graham
> --
>
>

Re: Windows Laundry List

[Jorge Schrauwen]

On Tue, May 17, 2011 at 9:19 PM, William A. Rowe Jr.
 wrote:
> About the patch, yes this should go in.  I'm busy for a day or few
> but flagged your message to come back to it, if there is a bugzilla
> incident please tag it 'depends on' PR 49997.
>
> On 5/17/2011 11:10 AM, Jorge Schrauwen wrote:
>>
>> Do the argument from a few year back still hold for the ASF not
>> providing them themselves still hold true for 2.3/2.4?
>> IIRC it had to due with VC6 being used for 3rd party module
>> compatibility. With the release of 2.4 series around the corner maybe
>> now is a good time to discuss this again?
>
> Correction; VC6 was used for *source file compatibility* within the
> build.  dsp/dsw could be exported to makefiles, or loaded by later
> Developer Studio versions into vcproj/sln format.  It was the only
> 'one single representation' that worked.
>
> For binaries, we used the MSVCRT which could be linked using VC6,
> but not safely by VC7 or later without DDK include files corresponding
> to the NT team's MSVCRT (rather than the compiler team's MSVCRxxx mess).
> Too many things relative to the MSVCR binaries are macros with all sorts
> of static assumptions.
>
> If I start preparing binaries for 2.4 to www.a.o/dist/httpd at all,
> it would be both 32 and 64 bit, and will either be Mladen's suggested
> WinDDK approach (using system MSVCRT) or the VC10 SP1 (current) way,
> still using industry-standard make/nmake, not msbuild nor gui proj.
>
That's good news, I had a chat with Guenter Knauf about this mess during FOSDEM,
We briefly discussed LLVM but I never got it working (most likely due
to time reasons).

I have no strong opinion on going VC10 or WInDDK... as long as the
users can get both flavors of binaries here.

> We may have reached the fork in the road where it no longer makes sense
> to maintain both a gui dsp/vcproj and makefiles from the studio solution.
> VC 7/2002 dropped support for exporting makefiles; VC 10 drops support
> for converting dsp/dsw into vcproj files.  So if we want either dsp/dsw
> or vcproj/sln files, we may be at the point of adopting the subversion
> approach to generating these gui representations from makefiles or
> resources common to the unix build, as the apr project generates from
> the .
>
> We also continue to improve the interoperability with mingw/msys.
>
> Due to project and personal trolling, I've put the rest of the opinions
> on this (and certain individuals) into the /ignore list for now. I am happy
> to continue this dialog of what MS got wrong in the WinDDK approach,
> and why it may be just too much effort to ask users to assemble such
> a toolchain with comprehensive msvcrt link .lib's, and simply go with
> the VC10 optimizations and library (WinDDK includes a VC 9 generation
> of the compiler).  MSVCRT is the kindest to our users consuming the
> software, but VC10's MSVCR100 is much kinder to module packagers and
> developers who wish to link to the same clib with minimal pain.
>
Indeed a system MSVCRT would be cleaner,... but if I look at most of
my windows machines they have a whole set of runtimes installed raging
from 2005,2008,... usually with and without SP's...

Chances are the end user will already have whatever version is needed.
Personally I think having it easier for the developers to link their
binaries would in the end be better for the user, since more modules
will be available for them to use (in binary form).


Jorge

Re: Windows Laundry List

[Jorge Schrauwen]

I'm still all for this,
But do many people use a 64-bit variant of httpd it self? I've long
since switched to linux for both my server and my development
environment but still provide binaries I compile on my website. (If
I'm lazy I get about 2-3 mails per day asking for the newest release)

So here are some statistics from blackdot.be:
httpd/httpd-2.2.18-win64.rar101 (went up yesterday)
httpd/httpd-2.2.17-win64.rar16212
httpd/httpd-2.2.15-win64.rar15750
httpd/httpd-2.2.14-win64.rar10403
httpd/httpd-2.2.13-win64.rar3110
httpd/httpd-2.2.12-win64.zip801 
httpd/httpd-2.2.11-win64.zip14347
httpd/httpd-2.2.10-win64.zip1521
httpd/httpd-2.2.9-win64.zip 2666
httpd/httpd-2.2.8-win64.zip 2181
httpd/httpd-2.2.4_x64.exe   4859

I wonder about the overall usage, more people seem to be compiling
them themselves recently and some other websites probably offer them.

Do the argument from a few year back still hold for the ASF not
providing them themselves still hold true for 2.3/2.4?
IIRC it had to due with VC6 being used for 3rd party module
compatibility. With the release of 2.4 series around the corner maybe
now is a good time to discuss this again?

Kind regards

~Jorge



On Tue, May 17, 2011 at 7:17 AM, Gregg L. Smith  wrote:
> Hi folks,
>
> This was originally asked for by Jorge of blackdot.be back in July of 2006.
> http://marc.info/?l=apache-httpd-dev&m=115394468128469&w=2
>
> With the simple fact that every Windows computer I have seen being sold for 
> some time now being x64, I do not see any reason to hold back on this since 
> there is no functional change.
>
> His patch looks like it would give out a redefinition warning, so here's my 
> version. I'm using WIN64 where he uses _WIN64, the reason is both are being 
> used, the former is used in numerous files throughout httpd & APR, the latter 
> in mpm/winnt/child.c. My x64 conversion script defines WIN64 and the compiler 
> _WIN64 so for me both are covered. Feel free to use whichever you prefer.
>
> It would be nice to see this in both trunk & 2.2. Patch is against trunk, and 
> patches 2.2 with fuzz due to following lines being different.
>
> Thanks for your consideration in this matter.
>
> Gregg
>
>
>
>
>

FOSDEM

[Jorge Schrauwen]

Any httpd people coming to FOSDEM in Brussels, Belgium this weekend?

If so Saterday or Sunday?

I hope to go on Saterday... But need to clear something first :(


Kind regards

Jorge

-- 
~Jorge

Re: official httpd VC9 builds

[Jorge Schrauwen]

Right, command line builds where part of the reason for still using
VC6. Alteast that rings a vague bell.

If we provide VC9 builds for 2.4+, we could do a 32-bit and 64-bit one then...
But that would mean 3 (or 2) binary packages for windows which
could result in a lot of extra work :(

How are the current binaries for windows made? Script or manual?

~Jorge



On Mon, Jan 31, 2011 at 11:05 AM, Issac Goldstand  wrote:
> I believe also that wrowe mentioned to me that  we wanted to support
> command line (make) builds, and VC9 doesn't allow us to export makefiles.
>
> I'm +1 for making both VC6 and VC9 builds from 2.4 and on, like PHP does.
>
>  Issac
>
> On 31/01/2011 11:21, Jorge Schrauwen wrote:
>> Hi
>>
>> If I remember correctly wrowe said it was because a lot of 3rd party
>> modules use VC6.
>> Although that was a while ago so I could be wrong.
>>
>> If I'm indeed correct maybe  2.4 is a good time to switch to VC9?
>>
>> ~Jorge
>>
>>
>>
>> On Mon, Jan 31, 2011 at 10:06 AM, Ferenc Kovacs  wrote:
>>> Hi.
>>>
>>> I'm a php developer, and I'm using VC9 php builds on windows(PHP 5.3 doesn't
>>> support ), hence I'm using the apache httpd builds from apachelounge.com,
>>> because you guys only offer VC6 windows builds, and I'm too lazy to build
>>> myself.
>>> My question is: why is this the case? as far as I can tell, the project
>>> builds fine with VC9, so why don't you support the VC9 builds?
>>> I would prefer the official builds for VC9, if that would be an option.
>>> If I missed something obvious there, then please bear with me, I tried to
>>> find the answer in the windows section of the download page, the wiki, and
>>> the mailing lists, but without much luck.
>>>
>>> Tyrael
>>>
>
>

Re: official httpd VC9 builds

[Jorge Schrauwen]

Hi

If I remember correctly wrowe said it was because a lot of 3rd party
modules use VC6.
Although that was a while ago so I could be wrong.

If I'm indeed correct maybe  2.4 is a good time to switch to VC9?

~Jorge



On Mon, Jan 31, 2011 at 10:06 AM, Ferenc Kovacs  wrote:
> Hi.
>
> I'm a php developer, and I'm using VC9 php builds on windows(PHP 5.3 doesn't
> support ), hence I'm using the apache httpd builds from apachelounge.com,
> because you guys only offer VC6 windows builds, and I'm too lazy to build
> myself.
> My question is: why is this the case? as far as I can tell, the project
> builds fine with VC9, so why don't you support the VC9 builds?
> I would prefer the official builds for VC9, if that would be an option.
> If I missed something obvious there, then please bear with me, I tried to
> find the answer in the windows section of the download page, the wiki, and
> the mailing lists, but without much luck.
>
> Tyrael
>

Re: [vote] Release mod_ftp 1.0.0 as GA

[Jorge Schrauwen]

~Jorge



On Fri, Oct 8, 2010 at 7:55 AM, Jorge Schrauwen
 wrote:
> ~Jorge
>
>
>
> On Fri, Oct 8, 2010 at 4:23 AM, William A. Rowe Jr.  
> wrote:
>> After some discussion on list about the numbering and quality of mod_ftp
>> today, it seems this is an appropriate time to consider GA, candidate
>> tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please
>> vote...
>>
>>  +/-1
>>  [X] Release mod_ftp 1.0.0 as GA
>>
> Seems good, not load tested it though.
Oops forgot: Using gentoo
>

Re: [vote] Release mod_ftp 1.0.0 as GA

[Jorge Schrauwen]

~Jorge



On Fri, Oct 8, 2010 at 4:23 AM, William A. Rowe Jr.  wrote:
> After some discussion on list about the numbering and quality of mod_ftp
> today, it seems this is an appropriate time to consider GA, candidate
> tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please
> vote...
>
>  +/-1
>  [X] Release mod_ftp 1.0.0 as GA
>
Seems good, not load tested it though.

Windows installer package, missing modules

[Jorge Schrauwen]

Hey,

I downloaded the latest windows msi (with ssl) because I had no time
to manually compile.
I noticed mod_reqtimeout.so is missing but it is available in the
default httpd.conf

Maybe it should be removed (or the module included) so users don't
accidentally enable it.
Well, if it something that can be easily done. Most usually will
probably figure out the error when they uncomment it.


Kind regards

Jorge

Re: Reducing number of mod_lua hook directives

[Jorge Schrauwen]

+1

~Jorge


On Mon, May 10, 2010 at 9:41 PM, Jeff Trawick  wrote:

> On Mon, May 10, 2010 at 3:25 PM, Brian McCallister 
> wrote:
> > On Mon, May 10, 2010 at 11:02 AM, Dan Poirier  wrote:
> >> mod_lua has 8 separate directives for adding hooks using external files
> >> with Lua code (LuaHookX) and 8 more for adding the same hooks using
> >> inline Lua code ().  Most of the code to implement these
> >> is common.
> >>
> >> I think it'd be easier to understand - and document - the module if we
> >> cut these down to two directives, with an additional argument to
> >> indicate which hook is involved.  E.g. change
> >>
> >> LuaHookAccessChecker /path/to/script.lua  funcname
> >> LuaHookAuthChecker   /path/to/script.lua  funcname
> >> LuaHookCheckUserID   /path/to/script.lua  funcname
> >> ...
> >>
> >> to
> >>
> >> LuaHook AccessChecker /path/to/script.lua  funcname
> >> LuaHook AuthChecker   /path/to/script.lua  funcname
> >> LuaHook CheckUserID   /path/to/script.lua  funcname
> >
> > This makes a ton of sense to me.
>
> +1
>

Re: AVG gives warning unpacking 2.2.15-win32 source

[Jorge Schrauwen]

On Fri, Mar 12, 2010 at 7:10 PM, William A. Rowe Jr.
 wrote:
> On 3/12/2010 12:06 PM, Jorge Schrauwen wrote:
>> I'm about to build the x64 binaries for on my website and AVG on my
>> development machine throws this at me.
>>
>> Warning: XML Bomb:
>> srclib/apr-util/test/data/billion-laughs.xml
>>
>> See attached screenshots, most likely harmless but not a nice welcome
>> when unpacking the source.
>
> You would rather we not warn you of the vulnerability, when you compile 
> against
> your existing expat?
>

So it's AVG's that's broke? Still sucks that AVG makes it appear that
the xml file is bad.

On Fri, Mar 12, 2010 at 7:20 PM, Gregg L. Smith  wrote:
> On Windows?
>
> My suggestion originally was to remove it only from the Win32 zip.
>
> Gregg

Yep, this was with the windows source zip

On Fri, Mar 12, 2010 at 7:16 PM, Gregg L. Smith  wrote:
> Hi Jorge,
>
> I brought this up quite some time ago, which is why I have been moving away
> from AVG since I was basically ignored here :-) That and AVG's many false
> positives. What is worse is, that XML bomb wont hurt anything anymore, and
> it can be gotten around AVG as well just by adding a certain amount of more
> recursions. I will not post the exact number, but at some point it will be
> bypassed.
>
> My thoughts on this is if this problem is fixed, why does there need to be a
> test against it anymore other than breaking said fix in the future and
> therefore becoming vulnerable again.
>
>
> Gregg

Oh didn't notice it back then, any recommendation for a for a free AV
product for windows?
Don't feel like forking over money to just run it on my test system
which runs like... maybe 3h per httpd release to get my x64 binaries
build.



Well if it's harmless and posted before, sorry for not noticing the
original post.

Jorge

Re: Apache devs attending FOSDEM 2010?

[Jorge Schrauwen]

On Wed, Jan 27, 2010 at 11:58 PM, Alex Wulms  wrote:

> Op donderdag 14 januari 2010 14:28:42 schreef Martin Langhoff:
> > On Mon, Jan 11, 2010 at 8:49 PM, Nick Kew  wrote:
> > > I've booked into the renaissance hotel -
> > >
> http://www.marriott.com/hotels/travel/brubr-renaissance-brussels-hotel/
> >
> > Cool -- that's in my neighbourhood, though a tad long to walk from home
> :-)
> >
> > >> If so, it'd be great to get together
> > >
> > > +1.  Will you be at the Friday beer event?  Were you thinking in terms
> > > of an apache-specific get-together on Saturday or Sunday evening?
> > > Or other ???
> >
> > I'll probably miss the Friday beer (I'll be returning from a trip that
> > very night), but Saturday afternoon or Sunday anytime we can stage a
> > get together. I'll be the guy running around with laptops with green
> > ears ;-)
> Hi,
>
> I prefer Saturday afternoon or evening.
>
>
> Kind regards,
> Alex
>

I'm 90% certain I'll be there on Saturday.

Would be a nice ending to my exam period :)

Re: Apache devs attending FOSDEM 2010?

[Jorge Schrauwen]

Thats actually not to far for me to drop by one of the days.
1 bit of relaxing after the exams!

Would be nice to finally meet some people I only know from online and irc.

~Jorge


On Mon, Jan 11, 2010 at 8:49 PM, Nick Kew  wrote:

> Martin Langhoff wrote:
>
>> Hi list,
>>
>> are any developers of apache (core, modules) coming to FOSDEM in Brussels?
>>
>
> Yeah, me.  I keep thinking we should consider an apache room there,
> but each year I'm too late to do anything.  Bah.
>
> I've booked into the renaissance hotel -
> http://www.marriott.com/hotels/travel/brubr-renaissance-brussels-hotel/
> Stayed there last year and was well-impressed.  Walkable both to the
> city centre and to FOSDEM.  Recommended if you haven't already booked
> somewhere to stay.
>
>
>  If so, it'd be great to get together
>>
>
> +1.  Will you be at the Friday beer event?  Were you thinking in terms
> of an apache-specific get-together on Saturday or Sunday evening?
> Or other ???
>
> --
> Nick Kew
>

Re: [VOTE] Formal deprecation of 1.3.x branch

[Jorge Schrauwen]

On Wed, Jan 6, 2010 at 12:30 AM, William A. Rowe Jr.
 wrote:
> Res wrote:
>> On Tue, 5 Jan 2010, Jorge Schrauwen wrote:
>>
>>> On Mon, Jan 4, 2010 at 11:03 PM, Rich Bowen  wrote:
>>>> Speaking from the community that provides end-user support for these
>>>> products, a big +1 on that proposal.
>>>>
>>> Sadly, questions will keep on showing up for a long time :(
>>
>> I agree, however if it is EOL'd (yes Jeff, I agree this is likely more
>> of an appropriate term :) ) you more or less can advise the requestor
>> they are using a very old and unsupported version and that they should
>> use the current stable version 2.2.xx
>
> These questions aren't a bother on an established 1.3 server, we all have
> to support legacy systems.
>
> What is frightening is the number of users who are clearly deploying their
> httpd server with 1.3, for the first time, and trying to learn that.  Almost
> want to suggest to them that they go take a community college class on COBOL
> while they are at it, since they are clearly trying to improve their technical
> knowledge.  Heh
>

You could just put a anti troll like system where you ask a question
only someone who's used 1.3 for a long time would know before letting
them download. New users wouldn't be able to answer it and would be
pointed to 2.2 branch ;)


It's understandable that you can't just magicly update a legacy 1.3 to
a 2.x series without breaking a whole lot of stuff.
But's sadly as you say, a lot users seem to be new to httpd and still
grab 1.3 for some insane reason!

Maybe adding some form of color coding (for the non-colorblind) on the
download page, green -> current, orange/yellow -> old stable, red ->
EOL
Then again that would probably not have a big effect :(

I also think punch cards > COBAL course! That will teach em to proof
read there code before hitting compile ;)

/me off to more studying

Jorge

Re: [VOTE] Formal deprecation of 1.3.x branch

[Jorge Schrauwen]

On Mon, Jan 4, 2010 at 11:03 PM, Rich Bowen  wrote:
> Speaking from the community that provides end-user support for these
> products, a big +1 on that proposal.
>
Sadly, questions will keep on showing up for a long time :(


On Tue, Jan 5, 2010 at 3:11 PM, Noirin Shirley  wrote:
> On Tue, Jan 5, 2010 at 3:18 AM, Dan Poirier  wrote:
>> Colm MacCárthaigh  writes:
>>
>>> Because ... stealing an idea from wrowe@ ... how about we formally
>>> deprecate the 1.3.x branch? Make one more release, but attach a notice
>>> to the effect that it will be the final release, and that in future
>>> we'll be distributing security updates by other means :-)
>
> +1! Yes please :-)
>

+1 (non-binding) There are still to many questions about the 1.3
branch on the support channels IMHO

>>
>> While we're at it, how about issuing a statement regarding how much
>> longer 2.0.x will be supported?  It doesn't seem to get much maintenance
>> attention these days either.
>
> Also +1
>
+1 (non-binding)

> N
>

Re: A fundamentally secure Apache server, any interest?

[Jorge Schrauwen]

On Mon, Nov 16, 2009 at 5:11 PM, Sander Temme  wrote:
> Hi Kevin,
>
> Definitely not the right list: this is where we discuss development of the 
> Apache HTTP Server code.  us...@httpd.apache.org may be a better forum within 
> apache.org.  Outside Apache, several initiatives exist to look into hardening 
> web servers.  The Center for Internet Security  
> is one of them.
>
> On Nov 16, 2009, at 8:42 AM, Sweere, Kevin E CTR USAF AFRL/RYT wrote:
>
>> I work for the US Air Force.  We have a prototype that dramatically,
>> fundamentally increases a web server's security.
>>
>> We run an Apache server within a minimized, user-level-only, Linux variant
>> only within RAM and from only a DVD (no harddrive).  With no shells, hackers
>> have nowhere to go.  With no persistent memory, malware has no place to
>> reside.  A simple reboot restores the website to a pristine state within
>> minutes.
>
> I agree.  Putting the entire OS and content on a read-only device (whether 
> DVD or otherwise) significantly reduces your exposure to attacks for all 
> these reasons.  The OS will need *some* writable space (like /tmp and 
> /var/run), but I assume you made like Knoppix and Ubuntu Live and their ilk, 
> and use RAM disks for that.
>
>> Because a LiveDVD holds the OS, apps and content, its best for static,
>> non-interactive, low-volume, high-value, highly-targeted websites.  Any
>> change means burning a new DVD, but this also makes testing easier and less
>> noisy.  Logs are tricky to extract.
>
> You could write logs to a RAM disk, with obvious implications on retention.  
> Or you could spool them to another server either through a network mount or 
> mod_log_spread.  The httpd configuration language allows you to put log files 
> in any place you like, and there are several approaches to rotating log files 
> if space is an issue.  Or you can use a third party module to write logs like 
> the aforementioned mod_log_spread, which is not part of httpd itself.
>
>> While it has worked well, some of us believe its usability drawbacks (e.g.
>> limited ability to receive input from users, every change needs a new DVD)
>> outweigh its great security benefits making it unmarketable (in govt or
>> industry) and thus just another prototype to leave on the shelf.
>
> You are in for a perpetual war between Operations (whose pager goes off when 
> things break) and dev (whose time-to-market is implicated by the fixed 
> environment).  You could mitigate that problem by reading site content from a 
> remote machine, either continuously over a network mount or by copying it 
> into a RAM disk on boot.  The former might be slower, but would allow for 
> more frequent site updates.  It's a trade-off, as usual.
>
> Keeping the remote mount read-only (even for root) will allow you achieve 
> your goal of a read-only environment.
>
> More comprehensive upgrades that would involve adding modules or changing 
> configuration parameters should trigger a change management process that 
> would lead to an update of the boot image.
>

You could just mount everything ro from a remote host then, even the
config for example, could be mounted from a remote host.

I guess a rw usb key with OS + config would work too if you can
somehow force it ro only when booting from it.

>> I'm curious what your group thinks.  Thanks in advance -- I don't quite know
>> with whom to discuss this idea.
>
> As Mark points out, this would be very secure but very hard to manage, and my 
> impression is that time-to-market pressure and available expertise frequently 
> cause ideas like this to fall by the wayside.
>
> Fundamentally, booting web heads from a read-only medium like an optical 
> drive or PXE is a sound idea.  Any initiative, installation method or 
> distribution that makes this easier to manage might increase adoption.
>
> S. I'd base it on BSD though
>
> --
> Sander Temme
> scte...@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF
>
>
>
>

Thats all that comes to mind atm.

Jorge

Re: Httpd 3.0 or something else

[Jorge Schrauwen]

I'm with Jim,

Head for 2.4 first.

IIRC there was some talk about moving to a 'd' project, since httpd
now does ftp (mod_ftp), echo, pop3,... and some other protocols.
I don't remember much from it though. I did like the idea back then
but thats about the only thing I remember from that.

Maybe we could also poll the user base? I know there was a restart on
the debate about the current conf and lua/perl/whatever not so long
ago so maybe these are all things to look into again for a 3.0?

Just my .2 cents

/me off to studying windows 2008 server -_-

~Jorge



On Wed, Nov 4, 2009 at 8:30 PM, Jim Jagielski  wrote:
> Let's get 2.4 out. And then let's rip it to shreds and drop
> buckets/brigades and fold in serf.
>
> On Nov 4, 2009, at 1:26 PM, Akins, Brian wrote:
>
>> So, after several conversations at Apachecon and on the list, we still
>> have
>> no real "vision" of how we want to move ahead with httpd "3.0."  Or, if we
>> do, it's not communicated very well.
>>
>> Some have suggested we just create a new server project. Others want to
>> keep
>> hacking away at the current code base.
>>
>> Thoughts?
>>
>> --
>> Brian Akins
>>
>
>

Re: [VOTE] release httpd mod_ftp-0.9.6 beta?

[Jorge Schrauwen]

~Jorge
  [X] +1 to release as 0.9.6-beta

Works ok here on linux (gentoo)


On Tue, Sep 29, 2009 at 5:28 AM, William A. Rowe, Jr.
wrote:

> Following Rainer's Solaris discoveries and our DISTDIR suggestions,
>
> Please fetch up the newly prepared mod_ftp-0.9.6.tar.gz (or .bz2), or the
> win32/netware/os2 suitable package mod_ftp-0.9.6-crlf.zip from;
>
>  http://httpd.apache.org/dev/dist/mod_ftp/
>
> review, take it for a spin, and cast your choice
>
>  [ ] -1 for any release of 0.9.6 (regressed from 0.9.2 or earlier?)
>  [X] +1 to release as 0.9.6-beta
>  [ ] +1 to release as 0.9.6 GA
>
> For getting started,
>
> http://httpd.apache.org/mod_ftp/
>
> and
>
> http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.6/README-FTP
>
> Bill
>
>

Re: [Fwd: Re: vote on concept of ServerTokens Off]

[Jorge Schrauwen]

I'm not too fond of being able to remove it either.

It can always be set to "Apache" with the current configuration
options and that should keep people worried about exploits somewhat
satisfied.

Even if you where able to hide it completely a good script could
figure out if it's a 1.3 2.0 or 2.2 based on how it handles retain
requests and on the Directory listing for example.

As

~Jorge



On Tue, Sep 1, 2009 at 11:36 PM, William A. Rowe,
Jr. wrote:
> Why attach email doesn't work in thunderbird is beyond me...
>
> This was Jeff's starting point for documenting ServerTokens Off.
>
>
>  Original Message 
> Subject: Re: vote on concept of ServerTokens Off
> Date: Wed, 6 Dec 2006 13:43:49 -0500
> From: Jeff Trawick 
> Reply-To: dev@httpd.apache.org
> To: dev@httpd.apache.org
> References: <200612061412.kb6ecwb10...@devsys.jagunet.com>
> 
> 
> <4576f73a.3020...@force-elite.com>
>
> On 12/6/06, Paul Querna  wrote:
>
>> This thread is making me sad.
>
> No tears ;)  The somewhat bright side is that pushing on this tender
> spot until it hurts should at the very least avoid having the same
> discussion here for the next couple of years, and at the most can
> avoid a lot of other wasteful discussions permanently ;)  The middle
> ground of document explicitly why you can't directly turn it off
> should also be achievable.
>
> Proposed documentation for the ServerTokens directive.
>
> Special note:
>
> Apache HTTP Server users suggest from time to time that the
> ServerTokens directive allow the Server response header to be
> eliminated completely.  This feature suggestion is rejected for the
> following reasons:
>
> * The Apache HTTP Server project wants surveys of web server usage,
> such as the well-known Netcraft survey, to more accurately represent
> the actual use of Apache httpd.  While some web server administrators
> currently modify the Apache HTTP Server source code or install
> third-party modules which can remove the Server header, too few
> administrators do this to significantly alter the results.  The same
> may not be true if it is an easily-accessible feature.
>
> * The Apache HTTP Server project believes that most people who want to
> avoid sending the Server header mistakenly think that doing so may
> protect their server from attacks based on known flaws in older Apache
> HTTPD releases, when in fact the only reasonable way to address these
> flaws is to upgrade to new Apache HTTPD releases which correct
> security problems affecting your configuration.  By restricting the
> ability to configure Apache in this manner, we wish to raise awareness
> of the need to upgrade when critical vulnerabilities are addressed.
>
> (what other reasons go here?)
> .
>
>

Re: HTTP mode on Apache not working

[Jorge Schrauwen]

Hi Madhuri,

Please direct your question towards us...@httpd.apache.org, include
more information than this too.
Part of your config would be helpful.

Kind regards

~Jorge



On Thu, Aug 27, 2009 at 1:11 PM, Madhuri wrote:
>
> Hi All - This is the first time I am setting up apache server. It works fine
> on SSL mode with https://XX/, however it does not work with
> http://XX/. Will really appreciate any help.
>
> Thanks
> Madhuri
> --
> View this message in context: 
> http://www.nabble.com/HTTP-mode-on-Apache-not-working-tp25167526p25167526.html
> Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
>
>

Re: Apache HTTP Server development

[Jorge Schrauwen]

Speaking of fastCGI, wasn't a fastCGI module donated to the incubator?

Maybe it's time to look more into it if people aren't already.

~Jorge



On Mon, Aug 24, 2009 at 8:24 PM, Akins, Brian wrote:
> On 8/24/09 1:58 PM, "Paul Querna"  wrote:
>
>> They then switch to lighttpd, because it is so much faster, mostly
>> because it runs all the dynamic langauges via FastCGI, like we should.
>
> +1
>
> I still like the idea (maybe it was yours, Paul) of running basically
> everything externally using HTTP as the protocol.  Especially, if we
> supported things like basic external process management (like fcgid ) and
> ability to use domain sockets as well as TCP (it may be academic, but there
> can be some nice performance gains).
>
> I still like lua embedded, though. (Or something similar)
>
>
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Re: A single IP address and Domain name serving many servers

[Jorge Schrauwen]

You can do this with mod proxy.

# Proxy Forwarding

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so


ProxyRequests Off

Order allow,deny
Allow from all


#forward /siteX to backend server
ProxyPass /site1/ http://10.0.0.2/
ProxyPassReverse /site1/ http://10.0.0.2/

ProxyPass /site2/ http://10.0.0.3/
ProxyPassReverse /site2/ http://10.0.0.3/


Alternatively you can use sub-domains too if you have control over
both dns and apache.
site1.example.org ---> WAN IP --> LAN IP where apache does namevirtualhosting
site2.example.org ---> ...

Also support questions should go to us...@httpd.apache.org and not
dev@, this mailing list is for development related discussion.

Jorge Schrauwen



On Wed, Aug 12, 2009 at 6:01 PM, Branquim wrote:
>
> I want to know if its possible and how to do it...
>
> I have one valid ip address and one internet domain.
>
> What I want to do is:
> - when a client access my domain with: www.mydomain.com on his web browser
> he access my apache server apache1.localnetwork 10.0.0.1 (I already do this
> through nat in iptables).
> - when he types www.mydomain.com/site1 I serve him with another apache
> server inside my local network (apache2.localnetwork 10.0.0.2).
> - when he types www.mydomain.com/site2 he access another server
> apache3.localnetwork 10.0.0.3.
>
> How can I do this redirection with the client passing me just another uri
> and I serving him with different apache servers, having only an external ip
> and domain name?
>
> Thanks.
> --
> View this message in context: 
> http://www.nabble.com/A-single-IP-address-and-Domain-name-serving-many-servers-tp24939564p24939564.html
> Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
>
>

Re: Main httpd web site page: update needed for 2.2.13

[Jorge Schrauwen]

On Tue, Aug 11, 2009 at 7:40 PM, Guenter Knauf wrote:
> all,
> Guenter Knauf schrieb:
>> good idea! Based on this here modified samples:
>> http://people.apache.org/~fuankg/testhttpd/releases.txt
>> http://people.apache.org/~fuankg/testhttpd/main_index.txt
>> and final result:
>> http://people.apache.org/~fuankg/testhttpd/main_index.html
> before it again vanishes from radar - should I proceed and check-in the
> SSI stuff into svn? should be easy to revert if it turns out as bad, or?
Not that I have anything to say on this but I agree with the if it's
bad, you can revert so I say go for it.

>
> Gün.
>
>
>
>
>

Re: William Rowe Jr. is now V.P., Apache HTTP Server

[Jorge Schrauwen]

Congrats Bill!


... although my internal understanding of the ASF is limited I seem to
recall this is rather huge :)

~Jorge

Re: FTP open questions

[Jorge Schrauwen]

On Tue, Jul 14, 2009 at 2:28 AM, William A. Rowe,
Jr. wrote:
> Just finished the last showstopper.  I would be happy to advance this
> to release / general availability vote with the next release, if we can
> determine just a few oddball issue resolutions.  Jim and I have already
> gone ahead and moved many internal interfaces out of the private headers,
> which was my motivation for holding off a year ago.
>
> Should we advertise the commands we have not implemented, or remove them?
Yes, It's always useful to know for a more advance user.
>
> Should we alert the user to the ServerAdmin address in the HELP contents?
Maybe reuse ServerTokens for this?

Full/OS => serveradmin + unimplemented commands
Minimal => unimplemented commands
Minor => only list implemented commands
Major => only list allowed commands
Prod => no help?

That way the server admin still has a say in it?

Not sure the extra coding is worth it though.

>
> Right now HELP offers up;
>
> 214-The following commands are recognized (* =>'s unimplemented).
>    FEAT    TYPE    RMD     QUIT    RNTO    PORT   *MODE    APPE
>   *ALLO    STOR    PWD    *STOU   *REIN    AUTH    MDTM    SYST
>    XMKD   *SITE    XCWD    PASS    PASV    DELE   *ACCT    EPRT
>    SIZE    XRMD    NOOP    LIST    REST    PBSZ    XCUP    NLST
>   *SMNT    XPWD    ABOR    PROT    HELP    CDUP   *STRU    RNFR
>    MKD    *STAT    RETR    CWD     EPSV    USER
> 214 Direct comments to [no address given]
>
> Just for reference, three popular linux servers respond with no
> unimplemented features, one offers "Direct comments to" admin address,
> one offers the website address of it's project, and one just ends with
> the result "Help OK"
>
> The admin has little control over which commands are supported (although
> which commands are -allowed- is another matter entirely :)  So it just
> strikes me as odd to direct comments with respect to the HELP inquiry.
>
>

Re: Help with worker.c

[Jorge Schrauwen]

If I'm not mistaken it's FIFO (First In, First Out).

~Jorge



On Wed, Jul 8, 2009 at 12:39 PM, ricardo13 wrote:
>
> Hi,
>
> I'm trying understand worker.c module.
> My doubt is about operation push() and pop().
>
> Push() add a socket in array fd_queue_t->data and Pop() retrieve a socket
> for processing.
>
> But what's the order of PUSH() ?? It adds in final queue ??
> And POP() ?? Retrieve a socket only before (elem =
> &queue->data[--queue->nelts];) ??
>
> Thank you
> Ricardo
> --
> View this message in context: 
> http://www.nabble.com/Help-with-worker.c-tp24389140p24389140.html
> Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
>
>

Re: Please Review! Path for os/win32/os.h - new reports Win64 when build for 64-bit

[Jorge Schrauwen]

I thought I did but couldn't find it.

I've create a new bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47418

~Jorge


On Wed, Jun 24, 2009 at 9:40 PM, Jorge Schrauwen
wrote:

> I can't remember,
>
> I'll open one tomorrow when I have access to my updated patch.
>
> ~Jorge
>
>
>
> On Wed, Jun 24, 2009 at 7:55 PM, Mario Brandt wrote:
> > Hi Jorge,
> > did you also open a bug in bugzilla?
> >
> > Mario
> >
> > On Fri, Jun 19, 2009 at 6:30 PM, Jorge
> > Schrauwen wrote:
> >> Sorry to dig up this old thread again but some users of my unofficial
> binary
> >> have been complaining that it still says Win32.
> >>
> >> So any chances somebody could look at this again. It's a rather trivial
> >> change I think.
> >>
> >> ~Jorge
> >
>

Re: Please Review! Path for os/win32/os.h - new reports Win64 when build for 64-bit

[Jorge Schrauwen]

Sorry to dig up this old thread again but some users of my unofficial binary
have been complaining that it still says Win32.

So any chances somebody could look at this again. It's a rather trivial
change I think.

~Jorge


On Wed, Jul 26, 2006 at 11:00 PM, Jorge Schrauwen  wrote:

> I just tried lots of diferent comment styles like #, ', ... till i found
> one that worked. never though there would be more that one... makes sence
> though, especially for larger blocks of comment.
>
> So here is an updated diff file.
>
> On 7/26/06, Ruediger Pluem  wrote:
>>
>>
>>
>> On 07/26/2006 10:10 PM, Jorge Schrauwen wrote:
>> > Ok this is my first path so please bare with me and review.
>> >
>> > Since I'm rather new to C I did a lot of research and testing on this.
>> > More information regarding the changes:
>> > http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx#S4
>> >
>> > --- os\win32\os.h ---
>> >
>> > --- os.h.orig2006-04-22 03:53:06.0 +0200
>> > +++ os.h2006-07-26 21:22:24.000516000 +0200
>> > @@ -38,7 +38,11 @@
>> > #include 
>> > #include 
>> >
>> > +//Checking the architecture we are compiling for (Itanium 64-bit, x64
>> > (AMD64/EM64T) or x86)
>>
>> I cannot comment on the subject itself as I am not a windows man, but only
>> on
>> the style: Please do not use C++ style comments like //. Please use always
>> /* */.
>> Regarding style the following page is very helpful:
>>
>> http://httpd.apache.org/dev/styleguide.html
>>
>> Regards
>>
>> Rüdiger
>>
>>
>
>
> --
> ~Jorge


os.h.diff
Description: Binary data

Re: Some ramblings on httpd config

[Jorge Schrauwen]

As long as the current system isn't replaced by an entire runtime like
program approach I'd be okay with it.

But why not take it a step further than just lua?
Wouldn't it be possible to expose a standardized set of commands,
functions, objects, whatnot to any language?

That start with mod_lua as the initial implementation but if at a
later date someone makes mod_lisp/mod_java/.. they all share about the
same objects where just the syntax would be different. Also the glue
would then also extend to not just lua.

That would also help to make it documenting it language independently
more doable. (wow thats a word?)

you could then talk about a "request" object having properties x,y and
z and it doesn't matter if you manipulate it via lua,java,perl

Then again this would probably cause a whole lot of overhead and would
force mod_lua to be rewriting a lot I guess.


~Jorge



On Tue, Jun 9, 2009 at 2:49 PM, Akins, Brian wrote:
> On 6/5/09 11:31 PM, "Graham Dumpleton"  wrote:
>
>> This last example wasn't even related to driving configuration. It was
>> in practice an actual handler hook implementation for request
>> processing, not configuration phases.
>
> The way I see it, we have artificially separated configuration from request
> processing.  If you squint and tilt your head just right, you can see that
> virtualhosts today are really just syntactical sugar over the if/else logic
> inside of core:
>
> Some pseudo request processing code to do same thing:
>  if listening_port == 80 then
>     if r.hostname == 'www.foo.com' then
>         
>     elseif r.hostname =~ /www\d.bar.[org|net]/
>     end
>  end
>
>
> Of course this could be further hidden from users with
> macros/functions/libraries/modules...
>
> Now, on the practical side, do we completely ditch the current config
> system.  Part of me says yes, but I know that will be -1'd to death.  So,
> I'd just like the ability to do something like this:
>
> LoadModule lua_module mod_lua.so
> Listen 80
> LuaRequestHandler /path/to/my/lua/handler.lua
>
> (or it can be inline  but have found that to be somewhat cumbersome)
>
> Because I don't want to rewrite mod_proxy in lua, it'd be nice to have just
> a little bit of glue that would allow me to use it in a more "scripty" sort
> of way:
>
> LoadModule proxy_module mod_proxy.so
> LoadModule proxy_http_module mod_proxy_http.so
> 
>  require httpd.proxy -- provided by mod_proxy glue
>
>  p = httpd.proxy.get_url('http://blah')
>
>
> (Of course, that example could be handled like we do in mod_rewrite)
>
> Currently, we can sorta do most request processing in lua. (FWIW, do the
> request phases make any sense in a world where the entire request process is
> handled by a "script"??)  What is missing is the glue to the other, useful
> parts of httpd - like cache, mod_dbd, proxy, etc.
>
> Sure, one of us could hack together some example glue here and there, but
> until we as a whole "get" why this is useful/important, it will be just
> another list of patches waiting to be reviewed.
>
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Re: [VOTE] release httpd mod_ftp-0.9.4 beta?

[Jorge Schrauwen]

 [X] +1 to release as 0.9.4-beta

I didn't have time to test the EPSV & EPRT, nor do I have enough
knowledge on the rfc to do so atm.

It does compile and is functional in my config, so it's certainly
usable at the moment.
So I'd like to see it hit beta.

~Jorge



On Tue, Jun 9, 2009 at 1:07 AM, William A. Rowe, Jr. wrote:
> mod_ftp fans;
>
> Let's try this one more time, here's a 0.9.4 candidate which should have
> none of the 2.0 or 2.2 compatibility problems of the previous attempt.
> Thanks to everyone who spent the effort reviewing that package!
>
> Please fetch up the newly prepared httpd-mod_ftp-0.9.4.tar.gz (available
> now), or the win32/netware/os2 suitable package httpd-mod_ftp-0.9.4-crlf.zip
>
>  http://httpd.apache.org/dev/dist/mod_ftp/
>
> review, take it for a spin, and cast your choice
>
>  [ ] -1 for any release of 0.9.4 (regressed from 0.9.2?)
>  [ ] +1 to release as 0.9.4-beta
>  [ ] +1 to release as 0.9.4-beta, and ready to tag GA (1.0.0)
>
> Please let us know if you test the two significant issues;
>
> CURRENT RELEASE NOTES:
>
>  * EPSV and EPRT need real world testing for different routing and DMZ
>    cases and validating a range of IPv6-enabled clients' interop.
>    Note many IPv4-only NAT routers appear to ignore EPRT commands,
>    even as they would fix up NAT addresses from PORT commands.
>
>  * Extra attention should be paid to PORT and EPRT connections, especially
>    when assigned low numbered ports, e.g. FTPActiveRange 20
>
> These are my serious hesitations in blessing the release 1.0.0 just yet.
> Please be brutal in respect to testing both aspects :)  Other protocol and
> API related showstoppers have been added with respect to the FEAT and OPTS
> extensions, which need small modifications to the API for "cooperation"
> between extension modules.
>
> For getting started,
>
> http://httpd.apache.org/mod_ftp/
>
> and
>
> http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.4/README-FTP
>
> Bill
>
>
>
>
>
>
>
>
>

Re: Some ramblings on httpd config

[Jorge Schrauwen]

On Thu, Jun 4, 2009 at 1:55 PM, Akins, Brian  wrote:
> On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" 
> wrote:
>
>> 1. There are many and large and complex configurations out in the world.
>
> Which is exactly why I want/need a better way to do them.  I'm currently
> using a template system to generate them.  However I wind up with dozens
> (and dozens) of vhosts that sometimes only vary by a statement or too.
>
On this I completely agree! Currently say fetching 100+ hosts from a
database that are basicly the same except domain, documentroot and
maybe 3 options like has php, has cgi,.. is a PITA.

mod_perl with database backend... works I guess but it's like taking a
nice car, strip the engine and gut donkey and cram the engine in the
donkey. Ok not what I wanted to write but can't describe it.

Like Graham mentioned mod_macro can be of some use here. however since
I'm looping in  perl I may as well push the 4 lines needed to httpd
instead of a one line macro replacemen.


> A contrived example:
>
>  -- lots of stuff
>  if r.hostname == "www.domain.com" then
>     -- a couple of things specific to this domain
>  elseif r.hostname == "www.domain2.com" then
> ...
>
>
> Of course, this example may could have a little lua glue to handle this
> situation.
>
>
> Also, I'm not just talking about lua being the config language, I want lua
> to "drive" the httpd process.  Ie, the above code gets ran on every request.
>
>> 2. I admit that some improvements are needed. How about an approach that
>> allows
>>    to embed a macro / scripting language into the current configuration 
>> system
>>    that allows you to do more advanced things if you need to.
>
> If we provided enough glue within our modules for lua, this this would be
> fairly easy.  I already fake this a bit with mod_lua and handlers that do
> most of the work.
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Maybe we're looking at it the wrong way?

Why not go more modular with this as well?
>From what I've understood from wrowe's explenation the internal config
tree seems very flexible so why not create multiple ways to manipulate
it?

module register "parameters,blocks,..." with the internal config
mangement thingy,
front ends then configure the modules using those interfaces.

It being a flat file, xml file, lua script, perl script,... having
little relevance to httpd itself.

Flat file would turn that info say for the command into something like
Documentroot /some/path

Lua format would turn that in something else, whilst an xml format way
turn it into /some/path

You could keep the current method for legacy use, implement an lua one
for more advance use, xml one because somebody was bored and wanted
it. Heck even a lolcode one because you could.

even mixing could be possible, have some general stuff in flatfile,
include a lua script to generate hosts which in its turn include a
flat file with shared config for each host.

Then again it would be hard to write documentation for this. Since
"documenroot" could then have many ways to be set from a users POV :(
so maybe not a great idea.

But I'm just trowing out the whacky brain twists I have.


Jorge

Re: Some ramblings on httpd config

[Jorge Schrauwen]

On Wed, Jun 3, 2009 at 10:55 PM, Niklas Edmundsson  wrote:
> On Wed, 3 Jun 2009, Jorge Schrauwen wrote:
>
>> I know I'm playing with fire now but...
>>
>> XML based config could solve a few of the problems, XML can also be
>> validated.
>>
>> I have to admit lua would be more flexible but I think most server
>> admins have atleast come into contact with XML... while not
>> necessarily the case with lua.
>
> Fire indeed.
>
> I've never seen lua except for Brians examples just now, and lua seems
> usable. XML is just as horrible as our current config scheme and wouldn't
> add much IMHO.
>

well I have to admit XML == fixing a few problems and probably adding lots more.

The example Bertrand Mansion posted does look acceptable to me and
like Rich I could probably live with it quite easly. But also looking
at some other examples I do fear for the madness that will ensure in
users@ and irc.

> I could add more fire to this, just to stir things up a bit:
>
> Those who can't grasp lua probably couldn't grasp our current config scheme
> either. I reckon those would be better served with a shiny web-based
> pointy-clicky config interface, and those people probably couldn't bother
> less what was happening under the covers...
>

True, I haven't looked much a lua before and it does seems acceptable.
I never thought of current method of being difficult to understand.
Then again I am a programmer and been using apache since it's early
1.3 days so most of my troubles in the past are probably covered under
a think layer of dust.

But I don't see how good documentation and some very well thought out
examples could not fix this for lua.

But also try to remember a lot of users@ and IRC PITA's are because
different distro (*cough*debian) ship horribly modified configs to
make it easier for the users.

I fear that if we make a bad choose now, we will see more of these
horrors in the near future.

That being said that me talking and the "user who wants a simple web
server"/"crazy person who tries to help people do that", the server
admin/developer in me screams yes yes yes! bye bye ugly mod_perl
driven config. (Well if we have DBD support at least :p)

> /Nikke
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     ni...@acc.umu.se
> ---
>  Acetone = What you do in exercise class...
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>

Re: Some ramblings on httpd config

[Jorge Schrauwen]

Well lets summerize:
We seem to agree some sort of change to the configuration system is needed?
We don't all seem to be it should be a program like language like lua.
Httpd devs seem to like lua so it has the highest chance of being implemented.

But I think I'll speak for most people helping in users@ and #httpd
that whatever is chose or changed should be documented and also be
somewhat idiot proof?

I've also noticed this sort of discussion has appeared a few times in the past.
Maybe it's also time to actually do something with this discussion
instead of letting it slowly fade?

~Jorge



On Wed, Jun 3, 2009 at 10:35 PM, Bertrand Mansion  wrote:
> On Wed, Jun 3, 2009 at 9:47 PM, Jorge Schrauwen
>  wrote:
>> On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian  wrote:
>>> On 6/3/09 2:45 PM, "Jorge Schrauwen"  wrote:
>>>
>>>> I have to admit lua would be more flexible but I think most server
>>>> admins have atleast come into contact with XML... while not
>>>> necessarily the case with lua.
>>>
>>> XML with conditionals. Please, make it stop...
>>>
>>> I think we are going to have to choose one way (the current way, lua,
>>> something else) and just go with it.
>>>
>>> Nice thing about lua is that the configuration is the runtime "script."
>>> There is no external and internal representation of things. (Well, not
>>> exactly, but close...).  Lua is fast enough to just run every request - most
>>> of the "hard" stuff is still in C.
>>>
>>
>> I think going with a language "X" based config system will just give
>> us more horrible questions and make it even harder to trouble shoot
>> things like request X works but request Y doesn't.
>>
>> You might as well provide a building block method and the config c
>> based, will scare off the more casual users just like lua and only
>> allow the oncs who know what they are doing write a decent
>> configuration. (ok that last one is maybe a bit over exaggerated but
>> going pure program language based is a very big learn before usage
>> curve)
>
> Lua is already used exclusively as a configuration language in many
> different softwares.
> It was actually first designed to be a configuration language and it
> was very successful in this area.
>
> "...To make a long story short, yes, we did develop Lua to solve a
> particular problem. Although we developed Lua in an academic
> institution, Lua was never an "academic language", that is, a language
> to write papers about. We needed an easy-to-use configuration
> language, and the only configuration language available at that time
> (1993) was Tcl. Our users did not consider Tcl an easy-to-use
> language. So we created our own configuration language..."
> -- http://www.computerworld.com.au/article/260022/-z_programming_languages_lua
>
>
> Lua can look like this :
>
> DocumentRoot = "/htdocs"
> ServerName = "www.example.com"
> VirtualHosts = {
>  "www.example.com" = { DocumentRoot = "/example.com/htdocs" }
> }
>
> It doesn't have to look like code. If you don't want to learn
> programming, you don't have to because Lua code can look like a
> configuration. I think that the current Apache conf style could be
> easily converted into Lua syntax without having to rely on anything
> too fancy for non-programmers.
>
> But if you need power, then Lua probably offers the cleanest and
> fastest available in scripting languages. So you can get the best of
> both worlds :)
>
>
> --
> Bertrand Mansion
> Mamasam
>

Re: Some ramblings on httpd config

[Jorge Schrauwen]

On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian  wrote:
> On 6/3/09 2:45 PM, "Jorge Schrauwen"  wrote:
>
>> I have to admit lua would be more flexible but I think most server
>> admins have atleast come into contact with XML... while not
>> necessarily the case with lua.
>
> XML with conditionals. Please, make it stop...
>
> I think we are going to have to choose one way (the current way, lua,
> something else) and just go with it.
>
> Nice thing about lua is that the configuration is the runtime "script."
> There is no external and internal representation of things. (Well, not
> exactly, but close...).  Lua is fast enough to just run every request - most
> of the "hard" stuff is still in C.
>

I think going with a language "X" based config system will just give
us more horrible questions and make it even harder to trouble shoot
things like request X works but request Y doesn't.

You might as well provide a building block method and the config c
based, will scare off the more casual users just like lua and only
allow the oncs who know what they are doing write a decent
configuration. (ok that last one is maybe a bit over exaggerated but
going pure program language based is a very big learn before usage
curve)

Jorge


> Mod_rewrite goes away, which is a good thing :)
>
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Re: Some ramblings on httpd config

[Jorge Schrauwen]

I know I'm playing with fire now but...

XML based config could solve a few of the problems, XML can also be validated.

I have to admit lua would be more flexible but I think most server
admins have atleast come into contact with XML... while not
necessarily the case with lua.


of course a sort of some lua config stuff
would be possible to

if httpd would export some binding glue module for example
lua,c,perl,... could be provided so complex configurations can
potentially be done in a language the admin is familiar with.

puts down the oil and matches and waits for the blaze to start.

~Jorge



On Wed, Jun 3, 2009 at 8:39 PM, Akins, Brian  wrote:
> On 6/3/09 2:09 PM, "Joachim Zobel"  wrote:
>
>> This does IMHO not address any of the problems users usually have and
>> that are mainly due to a lack of validation.
>
> First of all, I don't really care about "normal" users, to be honest. Admit
> it, I'm not the only one.  However, I do know that we can't just break
> everything for them.
>
>>
>> See
>> http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf
>> for what I consider a good description of the current problems.
>
> It solves most of the "Missing" page, I think. Also, if the lua doesn't
> compile, it's not a valid config.  A few of the other points are addressed
> by using lua with some "helper" libraries.
>
> We could ease into this by having modules provide some lua glue for use in
> the lua handlers (proxy and cache in particular).
>
>
>
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Re: [VOTE] release httpd mod_ftp-0.9.3 beta?

[Jorge Schrauwen]

That would do just fine.

Maybe worth documentation somewhere.
Honestly it was a oh that would be usefull for a lot of users kind of
idea that I didn't spend time researching much.

Are there actually any user statistics for mod_ftp?

~Jorge



On Sun, May 31, 2009 at 8:04 PM, William A. Rowe, Jr.
 wrote:
> Jorge Schrauwen wrote:
>> Trunk builds fine now.
>>
>> Just something that I noticed.
>> when the u...@domainx is used and domainX doesn't exist it will
>> default to the default vhost.
>>
>> could it be possible to make that configurable to say go to default or
>> deny connection?
>
> I don't want to solve in code what the code already solves.
>
> What about, in the default ftp vhost, using the VirtualHostByUser,
> configure for basic auth with an empty user list (or for your
> convenience you could have an admin here).  Require valid-user at
>  and we should be done.
>
> In the named hosts, using VirtualHostByUser plus optionally the
> StripHostname feature, set the appropriate access control.
>
> How would that do for solving the puzzle?
>

Re: [VOTE] release httpd mod_ftp-0.9.3 beta?

[Jorge Schrauwen]

Trunk builds fine now.

Just something that I noticed.
when the u...@domainx is used and domainX doesn't exist it will
default to the default vhost.

could it be possible to make that configurable to say go to default or
deny connection?


~Jorge



On Sun, May 31, 2009 at 10:58 AM, William A. Rowe, Jr.
 wrote:
> Guenter Knauf wrote:
>> William A. Rowe, Jr. schrieb:
>>
>>> Are you certain NetWare should be building the ftp_lowportd.c?  (It can,
>> no, it cant. How can we workaround this?
>>
>>> it seems that sys/un.h is found for unix pipe support).
>> argh! That's the reason why the APR_HAS_ is defined!
>
> I see no related APR_HAS_
>
> Have worked around this, testing explicitly for one of the variants of
> socket passing msghdr support.  (Actually, someone who cares about the
> mod_proxy_fdpass should really borrow this code).
>
> Fixed several other [miss-]detections, give this another shot.
>

Re: [VOTE] release httpd mod_ftp-0.9.3 beta?

[Jorge Schrauwen]

On Sun, May 31, 2009 at 12:06 AM, William A. Rowe, Jr.
 wrote:
> Jorge Schrauwen wrote:
>>
>> I'm not saying we shouldn't make it easy to provide and alternative
>> path for apxs it being a little config mod or be it a parameter.
>
> Neither was I :)  As Guenter pointed out, distros were "forced" to rename
> apxs to apxs2 because we failed to do so.  But what about the distinction
> between apxs2 and apxs22?  Or some apxs24 or apxs3 in the future?
>
> We should help people in this, but without distributors coming back and
> hollering "whoa! problem!" how do they expect to provide us with some
> standardized solution?  So they each invent their own, and then gripe
> when accommodating each of their their forks is rejected by the project?
>
> Guenter - your first challenge on httpd trunk is to convince the project
> that /usr/bin/apxs for 2.4/3.0 would be a stupid mistake to repeat, so
> that we change our ways :)  If your proposal involves naming it apxs2 or
> apxs3, then you might kill two birds in one stone.
>

Personally I'd go for renaming (backwards aswel to
apxs13
apxs20
apxs22
apxs30
...

and having apxs being a symlink of sorts
like "apxs -s 22" will set 22 as the default but also providing na one
time overwrite
something like apxs -v 22 will use it only for this runtime instance.

Not ideal but it does provide a long term solution but probably not ideal.

Re: [VOTE] release httpd mod_ftp-0.9.3 beta?

[Jorge Schrauwen]

~Jorge



On Sat, May 30, 2009 at 2:27 AM, William A. Rowe, Jr.
 wrote:
> Guenter Knauf wrote:
>> Sure that its possible to specify the full path at commandline, but tell
>> me a reason why we should make it harder for users than needed?
>
> The question is; which forks are we accommodating?  What scope?  .1% of
> installed userbase?  (whoops - better restore win9x quick!)  Seriously,
> if someone is using the fork, and grabbing packages, they just grab the
> mod_ftp package, so no big deal.
>
> Totally cool with adding a note to README-FTP about the APXS=apxs2 trick
> for those affected.
>
I'm for this as well.
People using the modded distro packages will most likely also install
mod_ftp from that distro.
The people that use say a distro's 1.3 package or a alt vendor package
in combination with a manual compile/vanilla implementation will most
hopefully be smart enough to understand the little changes that are
needed.

Personally I think that if distro's want to modify httpd to fit their
needs it also their job to modify modules to work with there modified
version.

I'm not saying we shouldn't make it easy to provide and alternative
path for apxs it being a little config mod or be it a parameter.

> I'm not disagreeing that it's potentially stupid for us to ship 'apxs'.
> I'm disagreeing that the appropriate place to fix conventions is here.
> And if folks don't want to play in such an open ecosystem, there is next
> to nothing we are going to fix in this, but we don't have to become party
> to perpetuating it.  Watching the good folks at users@, #httpd etc tear
> their hair out at vendor stupidity or cleverness is not 'fun'.
>
>
>

Re: [VOTE] release httpd mod_ftp-0.9.3 beta?

[Jorge Schrauwen]

Didn't have much time to tinker with it being exams and all but it
fails to build for me.

I do what I always do untar, ./configure.apxs, make, (make install)

Below you'll find the failed output. I'm not sure when I have time to
look into it.

But I guess some feedback is better than no feedback.

Jorge

---
shirayuki mod_ftp # ./configure.apxs
Configuring mod_ftp for APXS in /srv/httpd/bin/apxs
rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c
conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod
conftest_arpa_ftp_h conftest_netinet_ip_h
rm -rf .libs
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include  -prefer-non-pic -static
-c conftest_arpa_ftp_h.c && touch conftest_arpa_ftp_h.lo
rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c
conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod
conftest_arpa_ftp_h conftest_netinet_ip_h
rm -rf .libs
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include  -prefer-non-pic -static
-c conftest_fchmod.c && touch conftest_fchmod.lo
/srv/lib/build-1/libtool --silent --mode=link gcc -g -O2 -pthread
-L/srv/lib/lib   -o conftest_fchmod conftest_fchmod.lo
rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c
conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod
conftest_arpa_ftp_h conftest_netinet_ip_h
rm -rf .libs
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include  -prefer-non-pic -static
-c conftest_netinet_ip_h.c && touch conftest_netinet_ip_h.lo
rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c
conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod
conftest_arpa_ftp_h conftest_netinet_ip_h
rm -rf .libs
rm -f .deps Makefile

Finished, run 'make' to compile mod_ftp

Run 'make FTPPORT=8021 install' to install mod_ftp
(The default FTPPORT is 21 if not specified)

The manual pages ftp/index.html and mod/mod_ftp.html
will be installed to help get you started.

The conf/extra/ftpd.conf will be installed as an example
for you to work from.  In your configuration file,
  /srv/httpd/conf/httpd.conf
uncomment the line '#Include conf/extra/ftpd.conf'
to activate this example mod_ftp configuration.
shirayuki mod_ftp # make
Making all in modules/ftp
make[1]: Entering directory `/srv/.src/modules/mod_ftp/modules/ftp'
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
-DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c
ftp_commands.c && touch ftp_commands.slo
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
-DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c
ftp_data_filters.c && touch ftp_data_filters.slo
/srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread
-DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/modules/ftp
-I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I.
-I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c
ftp_filters.c && touch ftp_filters.slo
ftp_commands.c: In function ‘ftp_cmd_pass’:
ftp_commands.c:1080: error: ‘ap_loaded_modules’ undeclared (first use
in this function)
ftp_commands.c:1080: error: (Each undeclared identifier is reported only once
ftp_commands.c:1080: error: for each function it appears in.)
ftp_commands.c:1083: error: ‘ap_top_module’ undeclared (first use in
this function)
make[1]: *** [ftp_commands.slo] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/srv/.src/modules/mod_ftp/modules/ftp'
make: *** [all-recursive] Error 1
---


~Jorge



On Fri, May 29, 2009 at 10:14 AM, William A. Rowe, Jr.
 wrote:
> mod_ftp fans;
>
> We seem to have identified and solved our remaining 0.9.2 beta issues,
> so it's time for another, perhaps the final try on the way to GA!
>
> Please fetch up the newly prepared mod_ftp-0.9.3.tar.gz (available
> now), or the win32/netware/os2 suitable package mod_ftp-0.9.3-crlf.zip
> (still needs to sync in the next hour) from:
>
>  http://httpd.apache.org/dev/dist/mod_ftp/
>
> review, take it for a spin, and cast your choice
>
>  [ ] -1 for any release of 0.9.3 (regressed from 0.9.2?)
>  [ ] +1 to release as 0.9.3-beta
>  [ ] +1 to release as 0.9.3-beta, and ready to tag GA (1.0.0)
>
> Please let us know if you test the two signifi

Re: mod_ftp alpha/beta?

[Jorge Schrauwen]

I've been using it as fallback when I can't conenct to mine via webdav.

So far it's working ok, even vhosts but thats still a bit tricky but
works non-the-less.
I'd love to see it included for a 2.2.x but 2.4.x would be nice aswel.

~Jorge



On Tue, May 5, 2009 at 5:56 PM, William A. Rowe, Jr.
 wrote:
> Jim Jagielski wrote:
>> I'd like to work on a mod_ftp release to go along
>> with the 2.2.12 release... I think baselining mod_ftp
>> for only 2.2.x makes sense, and I'd really like to get a
>> release out.
>>
>> What's the status? I've done some prelim tests and they
>> look good.
>
> See STATUS?
>

Re: what is in modules vs what is in the core

[Jorge Schrauwen]

Maybe a more layered approach would be something to consider for 3.0?

Seems to me that the layers and groups of modules keeps expanding and expanding.

2.0 -> 2.2 had the whole auth move over so maybe it's time to rethink
the current module system for 3.0?

~Jorge



On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins  wrote:
>
> On Mar 30, 2009, at 7:37 PM, Paul Querna wrote:
>
>> mod_watchdog is the latest offender in a series of modules that expose
>> additional functions to the API. (mod_proxy and mod_cache do too!)
>>
>> What happened to all functions that are not inside server/* must be
>> either dynamic optional functions or hooks?
>
>
> Some modules (mostly 3rd party??) allow it either way - optional function or
> just linkage.  I'm personally a fan of hooks and providers.  (With
> providers, I usually just do the lookup once in, say, post-config, and
> "cache" the results in the "subscribing" module - this saves some hash
> lookups on potentially every single request.)
>
> As I hack on some lua stuff, it's useful to have the symbols for functions.
>  That may just be because I'm lazy, because I could do optional function
> lookups in library opens, I suppose.  OT, but I like my Lua glue in a lua
> module and just use "require 'apache2.memcache'" (or whatever) to do the
> linking.  This works really well with per thread lua states that are all
> loaded at startup... (hint, hint)
>
> --Brian
>

Re: accept mod_fcgid codebase into httpd project

[Jorge Schrauwen]

On Mon, Jan 12, 2009 at 12:59 PM,  wrote:

> On Jan 11, 2009 10:53pm, "William A. Rowe, Jr." 
> wrote:
> > Based on the enthusiasm of the module authors to adopt the AL and offer
> >
> > the mod_fcgid code to the httpd community, please vote
> >
> >
> >
> >  +/-1
>
> [+1]  Accept mod_fcgid into httpd
>

not that my vote counts but I think mod_fcgid's inclusion in the main httpd
will be a good think.
+1



>
>
> And "Thanks!" to the mod_fcgid author and contributors!

+1 to this as wel!

Re: [VOTE] Release Apache HTTP server 2.2.11

[Jorge Schrauwen]

Also note that the x64 versions of windows do run 32-bit binaries without a
problem.
I've been providing x64 binaries of httpd 2.2 because people want them.

I've moved from running windows on my servers to running linux. Even an old
128mb, P3 800mhz will run linux + httpd without a hitch.

I also like to see some nicer build stuff for windows.
But if a change does happen (I'd like to see it in 2.3 rather than 2.2). As
wrowe has pointed out to me in earlier discussions. The .net series of vs
are horrible in upgrade/downgrade wise.

It would be awsome to have a build platform thats cross platform like ant
but for c(++) I'm not sure that exists though. Never look.

As of now compiling x64 bit httpd binaries isn't easy. But it's doable.

~Jorge


On Fri, Dec 19, 2008 at 9:01 PM, William A. Rowe, Jr.
wrote:

> bing swen wrote:
> >
> > As made clear sometime earlier, Windows 2008 R2 will only have 64-bit
> versions. The clock is ticking
>
> Has built fine (with edits) from command line without visual studio,
> and .sln's won't be the sole mechanism as long as I have a veto;
> 1) MS needlessly introduces breaking changes into each successive VS
> product release in a vain attempt to lock-in and force-upgrade (e.g.
> the .vcproj formats, manifest etc etc), and 2) There's no way out of
> an .sln into a procedural makefile build.  Not even cmake or msbuild,
> at least the last time I looked.  It's lock-in, ergo it's locked out
> (as the sole resource).
>
> You are right, it's time to dump dsp/dsw but not because they will
> be replaced with vcproj/sln, although it would be nice to get there
> for all the reasons we discussed.  Much like simplifying the 64 bit
> build (which you can already get out of APR, APR-util etc).
>
> Your last observation was fun... have you actually ran Microsoft Vista
> SP1 x64 edition on a collection of assorted hardware?  As cool as it
> would be to replace 32 bit with only 64 bit binaries, there is a
> performance penalty and it will be years before this is robust enough
> for the vast majority.  Notice 2008 Server R1 was released in 32 bits?
> Wouldn't have happened if the world was ready.
>
> Bill
>

Re: Revise VC6 .dsp files -- was: [VOTE] Release Apache HTTP server 2.2.11

[Jorge Schrauwen]

IIRC there where problems with this. The update dsp doesn't compile clean on
vc6.
vc6 is still the compiler used for all office asf httpd binaries.

~Jorge


On Thu, Dec 18, 2008 at 3:00 PM, Bing Swen  wrote:

> Jorge Schrauwen wrote on 2008年12月18日 20:10
>
>  On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen  wrote:
>>
>>  Jorge Schrauwen  wrote on 2008年12月17日, 19:07
>>>
>>>
>>>  For the early httpd-2.2.x series it has compiled on Win64. Then again
>>>> it's
>>>> very picky in which platform you use.
>>>> Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with
>>>> platform SDK (not sure they are fix now).
>>>>
>>>>
>>>> How long will they be compilable? I don't know. I think it has more to
>>>> do
>>>> with the makefile(s) than with the code it self.
>>>>
>>>>
>>>>  There seems to be a bug in the project updating functions of VS2005/08:
>>> embedded \" char's in the .rc files always made a fatal error to the
>>> resource compiler (rc.exe), e.g.,
>>>
>>>  "... LONG_NAME="Apache HTTP Server" ..."
>>>
>>> If all the inner \" are replaced with \' (namely, """ to "'"),
>>> then the updated project files (.vcproj) will be OK to compile.
>>>
>>> Was this part of the problems with the makefile(s)?
>>>
>>>
>> Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that
>> upgrade.
>>
>> There is a more detailed explenation here:
>> http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64
>>
>>
>> ~Jorge
>>
>>
> I already read your nice tutorial there, and many thanks. But I just meant
> whether it is possible to just revise the "makefiles" (VC6 .dsp files) in
> the official httpd Win32 release package to make the updated Win64 project
> files directly compilable?
>
> Bing
>
>
>

Re: [VOTE] Release Apache HTTP server 2.2.11

[Jorge Schrauwen]

Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that
upgrade.

There is a more detailed explenation here:
http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64


~Jorge


On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen  wrote:

> Jorge Schrauwen  wrote on 2008年12月17日, 19:07
>
>
>> For the early httpd-2.2.x series it has compiled on Win64. Then again it's
>> very picky in which platform you use.
>> Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with
>> platform SDK (not sure they are fix now).
>>
>>
>> How long will they be compilable? I don't know. I think it has more to do
>> with the makefile(s) than with the code it self.
>>
>>
> There seems to be a bug in the project updating functions of VS2005/08:
> embedded \" char's in the .rc files always made a fatal error to the
> resource compiler (rc.exe), e.g.,
>
>   "... LONG_NAME="Apache HTTP Server" ..."
>
> If all the inner \" are replaced with \' (namely, """ to "'"),
> then the updated project files (.vcproj) will be OK to compile.
>
> Was this part of the problems with the makefile(s)?
>
> Bing
>
>
>
>

Re: changing mod_wombat's name

[Jorge Schrauwen]

I'd prefer mod_core_lua over mod_script_lua.

I don't really see a problem with mod_luau either, LoadModule directives are
usually added to the config if the module is built so I don't think typo's
will be a big issue.

~Jorge


On Wed, Dec 17, 2008 at 1:33 AM, Eric Covener  wrote:

> On Tue, Dec 16, 2008 at 7:17 PM, Greg Stein  wrote:
> > Yeah, that can be confusing with the natural language
> directives/concepts.
> >
> > mod_script_lua
> > mod_embedded_lua  (me likee this one)
>
> mod_core_lua?
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: Update on status of mod_wombat

[Jorge Schrauwen]

I think to tie it to a version is bad too. And could be very confusing.


On Wed, Dec 17, 2008 at 8:48 AM, Greg Stein  wrote:

> I think it would be a bad idea to tie it to a specific version.
>
> On Tue, Dec 16, 2008 at 19:59, Brian McCallister  wrote:
> > Another suggestion from the lua mailing list, and not a bad one...
> >
> > On Tue, Dec 16, 2008 at 5:53 PM, Jeff Pohlmeyer
> >  wrote:
> >> Just a thought...
> >>
> >> The Apache PHP module is named "mod_php5" and a quick google search
> >> for "mod_lua5" returned no results here.
> >>
> >>  - Jeff
> >>
> >
>

Re: [VOTE] Release Apache HTTP server 2.2.11

[Jorge Schrauwen]

On Wed, Dec 17, 2008 at 9:01 AM, Bing Swen  wrote:

>
> "Jim Jagielski"  wrote on 2008-12-14 23:24
>
>
>> On Dec 13, 2008, at 9:32 AM, Ruediger Pluem wrote:
>>
>>>
>>> 2. A number of non binding positive votes and positive feedback.
>>> 3. Binding votes:
>>>
>>>  0 -1
>>>  0 +0
>>>  8 +1 (Colm, Sander Temme, Brad, Jim, Bill, Lars, Jeff, Ruediger)
>>>
>>>  So the vote has passed.
>>>
>>> I will copy the release files to the dist directory now and give the
>>> mirrors
>>> about 24 hours to catch up. I plan to announce the release  officially by
>>> tomorrow evening CET.
>>>
>>>
>> Don't forget to update the various site files, announcements,
>> etc... as of this morning, 'http://httpd.apache.org/' and
>> 'http://httpd.apache.org/download.cgi' still refer to 2.2.10
>> with smatterings of 2.2.11 around
>>
>>
> It may seem to be an out of fashion question,
> but I hope anyone can give a clear answer:
>
> How long will we have a compilable Windows x64 httpd-x.y.z release?
> Infinitely long? ;-)
>
> Bing
>

For the early httpd-2.2.x series it has compiled on Win64. Then again it's
very picky in which platform you use.
Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with
platform SDK (not sure they are fix now).


How long will they be compilable? I don't know. I think it has more to do
with the makefile(s) than with the code it self.

~ Jorge

Re: changing mod_wombat's name

[Jorge Schrauwen]

wouldn't something like mod_lang_lua be better. Since not all future modules
could be script language.
Then again mod_lang_xx does look a bit odd.

~Jorge


On Tue, Dec 16, 2008 at 10:46 PM, Graham Leggett  wrote:

> Graham Dumpleton wrote:
>
>  Given that there could be a class of such scripting language modules
>> over time, why not:
>>
>>  mod_script_lua
>>
>> to make it more clear for what purpose it may be. Then fits in with
>> auth and proxy related modules having common prefix.
>>
>
> +1.
>
> Regards,
> Graham
> --
>

Re: todos for 2.3.1-alpha

[Jorge Schrauwen]

On Sat, Dec 13, 2008 at 6:10 PM, Frank  wrote:

> Paul Querna wrote:
>
>> [...]
>> Anything else anyone thinks would be good to get in?
>>
>
> I would like to see a better ErrorLog-handling/implementation.
> It should be similar to the LogFormat/CustomLog!
>
> There are others who want this too:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=29190
> (I wrote a patch for Apache which writes the servername in front of each
> error line so I can use a central errorlog file for solving the problem with
> the file descriptors. But a more flexible way should be implemented.)
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=29538 would be nice,
> too.
>
> Have fun,
>   frank
>

Speaking of logs. Maybe a system like we have the auth(n|z) now be used too.
Make it pluggable. Say a file version, maybe one that logs to a db. A syslog
one... then again this maybe should go in trunk and no 2.3.x series.

I was thinking something like that could come in handy when dealing with a
lot of host. (you could easly export logs per host from a table ;))


Just my 2 Cents

Re: changing mod_wombat's name

[Jorge Schrauwen]

On Mon, Dec 8, 2008 at 9:04 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2008, at 1:07 PM, Paul Querna wrote:
>
>> Brian McCallister wrote:
>>>
>>> I know some folks are attached to the wombat moniker, but the name is
>>> likely to confuse users, particularly now that it is in trunk.
>>>
>>> The obvious name, mod_lua, is a bit tricky as there are about half a
>>> dozen projects named "mod_lua" -- most of which are dead.
>>>
>>> I don't have a really good alternative, which is why the working name
>>> mod_wombat came into being, but I think leaving that name will cause
>>> user confusion.
>>
>> +1 to renaming, but I'm not sure we can or should call it "mod_lua".
>>
>> Any other ideas?
>
> mod_luau  
>
+1 on mod_luau, I like it!

> Roy
>
>

Re: changing mod_wombat's name

[Jorge Schrauwen]

+1 on renaming.
I still have to look up what it is every now and then. (Mostly due to
forgetting what it does all the time though)

mod_lua_handler, mod_lua_config meh I'm not good with names.

metal note: look at lua and mod_soonnottobewombat to replace to
replace buggy mod_perl stuff.

~Jorge



On Sun, Dec 7, 2008 at 11:36 PM, Tony Stevenson <[EMAIL PROTECTED]> wrote:
> Paul Querna wrote:
>> Brian McCallister wrote:
>
>>
>> +1 to renaming, but I'm not sure we can or should call it "mod_lua".
>>
>> Any other ideas?
>
>
> mod_pony:-)
>
>
> Cheers,
> Tony
>

Re: [VOTE] Release Apache HTTP server 2.2.11

[Jorge Schrauwen]

Custom compile on Gentoo (x86) +1

~Jorge



On Sat, Dec 6, 2008 at 11:04 PM, Res <[EMAIL PROTECTED]> wrote:
> On Sat, 6 Dec 2008, Ruediger Pluem wrote:
>
>> +1
>>
>> Tested on the following environments:
>>
>> Solaris 8 SPARC
>> Solaris 9 SPARC
>> Solaris 10 SPARC
>> Red Hat AS 4 32 Bit (x86)
>> Red Hat AS 4 64 Bit (x86_64)
>> Red Hat AS 5 32 Bit (x86)
>> Red Hat AS 5 64 Bit (x86_64)
>> SuSE Linux 10.2 32 Bit (x86)
>> SuSE Linux 11.0 32 Bit (x86)
>> SuSE Linux 10.1 64 Bit (x86_64)
>>
>
> +1
> Slackware 12.0 (x86)
> Slackware 12.1 (x86)
>
>
> --
> Res
>
> If you are not part of the solution, then you are part of the problem!
>

Re: Intent to Roll 2.3.0-alpha

[Jorge Schrauwen]

mod_perl comes to mind too.

To a lesser extend mod_security and mod_macro.

~Jorge



On Fri, Nov 28, 2008 at 10:06 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>
> On 11/28/2008 06:58 PM, Sander Temme wrote:
>>
>> On Nov 28, 2008, at 9:04 AM, Paul Querna wrote:
>>
>>> FYI, I intend to roll 2.3.0-alpha, our first release from trunk in
>>> about  3 years, on Saturday December 6th.
>>
>> +1, let's get that code out there.
>>
>> As part of this process, I would like us (the group) to identify *early*
>> which third party modules are popular with our userbase, and
>> pro-actively approach their vendors so that they know what we're doing.
>> Then they can make their plans to release without being blindsided.
>>
>> Off the top of my head I'm thinking:
>>
>> * PHP
>> * Oracle (WebLogic)
>> * Breach (ModSecurity)
>>
>> Let's throw this on the user list once the Alpha is out and see what's
>> important to them.
>
> +1 to this approach.
>
> Regards
>
> Rüdiger
>
>

Re: Time for 2.2.11?

[Jorge Schrauwen]

I'd prefere to have stable bug free (well as little as possible) release,

New feature are nice, but they can wait IMHO.

Just my 2 cents

~Jorge



On Sat, Nov 15, 2008 at 9:50 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> Not that much time has passed since we released 2.2.10 (one month), but
> I would like to see a release of 2.2.11 in the near future.
> Why?
> 2.2.10 has two regressions, one against 2.2.8 (crashes caused by the
> proxy) which is already backported and one against 2.2.9 (errors in
> openssl detection) which is currently proposed for backport and
> misses two votes.
> There are two further changes in the STATUS file that only miss one
> additional vote.
>
> With these 3 changes in the pipeline and the 10 changes already done
> for 2.2.11 I think we have enough stuff for a release given the
> two regressions above.
>
> I even volunteer to be the RM for this release and if the remaining
> proposals get in I would like to T&R on 29th / 30th of November and
> release on 6th / 7th of December if the voting passes.
>
> And yes I know some of us will be disappointed that some things will
> miss the boat again (especially SNI), but they wouldn't be in a 2.2.x
> release even if we do not release 2.2.11 at the beginning of December.
>
> Opinions?
>
> Regards
>
> Rüdiger
>

Re: httpd win64 "project" sources/makefiles [was:...binaries]

[Jorge Schrauwen]

cmake seems very interesting.
I'd like to help if you go that path, not sure I'll be of much use though.

~Jorge



On Mon, Nov 3, 2008 at 6:42 PM, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> On Nov 3, 2008, at 6:06 AM, Marc Noirot wrote:
>
>> What about going one step further and using a tool
>> able to generate Makefiles and IDE files for [name some of your favorite
>> IDEs] ?
>>
>> I'm thinking about something like CMake ...
>
> http://lwn.net/Articles/188693/
> http://www.cmake.org/
>
> +1
>
> But it still requires folks to do the work.  Hackathon?
>
> Roy
>
>

Re: httpd win64 binaries

[Jorge Schrauwen]

On Mon, Nov 3, 2008 at 10:23 AM, Bing Swen <[EMAIL PROTECTED]> wrote:
> Jorge Schrauwen <[EMAIL PROTECTED]> wrote on 2008-11-3 16:26
>
>> On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote:
>>
>>> Jorge Schrauwen wrote:
>>>>
>>>> The subject of not having an official binary package was brought up.
>>>> We couldn't think of a reason why not except no body wants or has the
>>>> time to do it.
>>>
>>> That's not it.
>>>
>>> The problem is MS's creation.  We can either ship an 'official'
>>> msvcrt.dll
>>> based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
>>> or 2008sp1 binary.  Let's face it, flavor of the week doesn't work for an
>>> approach to a C runtime.
>>>
>>
>> Now that you mention it I do seem to vaguely remember something about
>> this.
>> So unless the MS gets there act together (which I doubt will happen in
>> anytime soon) we won't see any 64-bit binaries?
>>
>
> Though we are eager to see an 'official' 64-bit Windows httpd release, but
> if not binaries, why shouldn't there be an x64 configured Apache.sln? It
> will be already great to let people have the chance to do their own x64
> compilation.
>
Currently there is only a .dsw and no sln's, they get generated on import.
For some project on import there is a x64 platform available but not all.

I'm not sure how doable that would be? If it was easy I'm sure someone
(wrowe) would probably have done this already. Easiest way to do it
with the current dsw/sln is to remove the project that have and x64
targets, then create a new x64 target for the entire solution.

> It was made clear that 32-bit will soon be over at the Windows server end
> (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx).
> I guess most of us still think that Windows Server remains as an important
> platform for Apache. So it's really time to make this "little" step further.
>
>
>>
>> So selecting a version that is most popular say 2005(sp1) and only
>> using that one is out of the question?
>>
>
> Jorge's Win64 binaries already seem to work perfectly on mainstream Windows
> versions. Shouldn't it be able to improve to be "offical"?
> (I just found it can not load some modules built with VS005/Win008, though).
>
I compiled them on vs2008 IIRC (not sure only boot into the vm when
need to compile)
Sadly the exact same version is needed or else it refuses to load.
That is what wrowe mentioned above with all the minor version bumps
here and there.

>
> Bing
>

Jorge

Re: httpd win64 binaries

[Jorge Schrauwen]

On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr.
<[EMAIL PROTECTED]> wrote:
> Jorge Schrauwen wrote:
>>
>> The subject of not having an official binary package was brought up.
>> We couldn't think of a reason why not except no body wants or has the
>> time to do it.
>
> That's not it.
>
> The problem is MS's creation.  We can either ship an 'official' msvcrt.dll
> based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
> or 2008sp1 binary.  Let's face it, flavor of the week doesn't work for an
> approach to a C runtime.
>

Now that you mention it I do seem to vaguely remember something about this.
So unless the MS gets there act together (which I doubt will happen in
anytime soon) we won't see any 64-bit binaries?


> I'm likely to ship that DDK built flavor if only to help ensure compatibility,
> and let the Studio team know that they don't know what they are doing.  They
> deliver a fun product for building something.  I know, I used it almost for
> 2 decades.
>

So selecting a version that is most popular say 2005(sp1) and only
using that one is out of the question?

> They are entirely clueless at delivering a product to be used across multiple
> developers from multiple organizations to accomplish multiple purposes.  They
> just can't grok that much multiplicity, and observe the central MS tenant of
> forcing to upgrade early and upgrade often.  This isn't compatible with open
> source binaries.  Just look at how frequently gcc is willing to bump the ver
> major like next to never.
>
>

But I have to agree, MS's vs 2005+ series is a mess with all the
.manifest and .local and bah!


~Jorge

httpd win64 binaries

[Jorge Schrauwen]

Hi All,

I was running a bit late about compiling the 64-bit windows binaries I
have on my site this month and mentioned on #apache-helpdesk how much
a pain it was.
The subject of not having an official binary package was brought up.
We couldn't think of a reason why not except no body wants or has the
time to do it.

Today I was checking some stats on my server and i though i'd share them:

Filename - downloads - last download
httpd/httpd-2.2.4_x64.exe 4859 2008/02/02 10:37:53
httpd/httpd-2.2.9-win64.zip 2666 2008/10/26 12:10:08
httpd/httpd-2.2.8-win64.zip 2181 2008/06/18 12:21:25
httpd/httpd-2.2.10-win64.zip 186 2008/11/02 22:59:47

httpd/httpd-2.2.9-win64_debug_symbols.rar 296 2008/10/25 21:20:37
httpd/httpd-2.2.8-win64_debug_symbols.zip 226 2008/06/18 12:21:32
httpd/httpd-2.2.10-win64_debug_symbols.zip 21 2008/11/02 08:59:34

httpd/mod_security2.1.1_x64.zip 1444 2008/11/02 08:59:57
httpd/mod_auth_xml_x64.zip 1408 2008/11/02 09:00:14
httpd/mod_jk1.2.22_x64.zip 1356 2008/11/02 09:00:04
httpd/mod_macro1.1.8_x64.zip 948 2008/02/02 07:44:45
httpd/mod_log_rotate_x64.zip 763 2008/11/02 09:00:21
httpd/mod_macro1.1.10_x64.zip 400 2008/11/02 08:59:49

I'm not sure what the 32-bit binaries have as download count but I
think around 2000-2500 isn't bad for binaries I host on my personal
website*.

So the question is... why are there no official binaries? There
definitely is some interest in this.
Also the fact that people mail and complain why I haven't released the
latest version when I'm late seems to suggest they do want them bad
and they are to lazy or can't compile them, themselves.

* sadly these binaries aren't complete and things like the apr-util
mysql driver are still missing. mod_deflate and mod_ssl are included
though.

Jorge Schrauwen

Re: Simple MPM is in trunk

[Jorge Schrauwen]

On Thu, Oct 30, 2008 at 10:44 AM, Bing Swen <[EMAIL PROTECTED]> wrote:

>  Jorge Schrauwen <[EMAIL PROTECTED]>  wrote on 2008-10-30 17:03
>
> On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen <[EMAIL PROTECTED]> wrote:
>
>> Paul Querna wrote on 2008-10-30 12:10
>>
>>>
>>> Bing Swen wrote:
>>>
>>>> Paul Querna wrote on 2008-10-28 15:12
>>>>
>>>> Hope you've included 64-bit Windows in mind. Make x64 Windows a
>>>> first-class citizen in httpd-2.4.x, please.
>>>>
>>>
>>> How is it not a first class citizen in 2.2.x?
>>>
>>
>> Here are some reasons:
>>
>> 1. Currently Win-x64 compilation is a painstaking mission (hopeless for
>> us), still no go to a 64-bit httpd.exe;
>>
>
> I have to admit it isn't easy to do so. But it certainly is possible!
> Due to lack of time on my part I've not updated the httpd wiki but you can
> find how to do it here:
> http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64
>
> First few times are the hardest but once you setup a nice build environment
> its all good.
> Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the
> best, although 2008 works too.
>
> If you can't be bothered with the trouble, there are unofficial binaries on
> there too if you want to play with it.
>
>
>>
>> 2. Many stock modules have no 64-bit configuration.
>
>
> Again it's a matter of recompiling, most windows users are spoiled and
> thing everything comes in nice binaries.
> libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for
> 64-bit, most are easier to do than httpd itself.
>
>
>
> Thanks for the nicely presented tutorial. I'll try to follow it and to
> understand what that 600+ PERL lines have fixed.
>
> So we have to get AWK, Bison, Flex and Sed to work, which are not required
> for a 32-bit build. And, we need a Perl Interpreter to run some "magic"
> conversions to get it built. That already made Win-x64 httpd a second-class
> citizen;)
>
>

the perl file doesn't do it's job completely though, you still need a
modified Makefile.win to fix some odd x64/release stuff that it wants in
release.

biggest problem atm is getting the apr dbd drivers for mysql and such.
(never got that to work)

 3. For some that compiles, there are lots of warnings of dangerous
>> conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64
>> like Linux.
>
>
>> 4. Suboptimal network i/o and so second-class performance. Native support
>> of IOCP (completion port) needs a mapping from requests (not connections) to
>> worker threads, so requires httpd to do some "connection scheduling"
>> ("suspendable connections" as discussed before).
>>
>> Bing
>>
>
> Personally I'd love to see the httpd project release 64-bit binaries
> themselves. But it's a lot of work for not much gain!*
>
> * tests with the early 2.2 branch show little to no improvements.
>
>
>
>
> The improvement is httpd's virtual memory -- and actually very significant:
> we need to map a 500+ GB index into the memory space of httpd's child
> process. 64-bit space is our only choice;)
>

Well a proxy with a mem_cache would definatly benifit from it.


>
> Bing
>
>
>
>

Re: Simple MPM is in trunk

[Jorge Schrauwen]

On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen <[EMAIL PROTECTED]> wrote:

> Paul Querna wrote on 2008-10-30 12:10
>
>>
>> Bing Swen wrote:
>>
>>> Paul Querna wrote on 2008-10-28 15:12
>>>
>>> Hope you've included 64-bit Windows in mind. Make x64 Windows a
>>> first-class citizen in httpd-2.4.x, please.
>>>
>>
>> How is it not a first class citizen in 2.2.x?
>>
>
> Here are some reasons:
>
> 1. Currently Win-x64 compilation is a painstaking mission (hopeless for
> us), still no go to a 64-bit httpd.exe;
>

I have to admit it isn't easy to do so. But it certainly is possible!
Due to lack of time on my part I've not updated the httpd wiki but you can
find how to do it here:
http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64

First few times are the hardest but once you setup a nice build environment
its all good.
Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the
best, although 2008 works too.

If you can't be bothered with the trouble, there are unofficial binaries on
there too if you want to play with it.



> 2. Many stock modules have no 64-bit configuration.


Again it's a matter of recompiling, most windows users are spoiled and thing
everything comes in nice binaries.
libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for
64-bit, most are easier to do than httpd itself.

3. For some that compiles, there are lots of warnings of dangerous
> conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64
> like Linux.
>
> 4. Suboptimal network i/o and so second-class performance. Native support
> of IOCP (completion port) needs a mapping from requests (not connections) to
> worker threads, so requires httpd to do some "connection scheduling"
> ("suspendable connections" as discussed before).
>
> Bing
>

Personally I'd love to see the httpd project release 64-bit binaries
themselves. But it's a lot of work for not much gain!*

* tests with the early 2.2 branch show little to no improvements.

~Jorge

Re: MPMs, COW vs Child Process Spawning

[Jorge Schrauwen]

On Wed, Oct 29, 2008 at 9:56 PM, Akins, Brian <[EMAIL PROTECTED]>wrote:

> On 10/29/08 3:40 PM, "Paul Querna" <[EMAIL PROTECTED]> wrote:
>
> > Of course, maybe that is a good thing, since then they would be ported
> > forward and work on win32 too.
>
> Can you delete open files in win32 yet??  If not, most of my stuff will not
> port...
>


Yes you can... although you need to force it.
Way back I use a library (for got the name) that had all kinds of winapi
stuff that was useful. Unlocking a file was one of them.
so it was unlock the file, then remove it. Down site is if the file is open
by some process all output will be lost.

~Jorge


>
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies
>
>

Re: MPMs, COW vs Child Process Spawning

[Jorge Schrauwen]

On Wed, Oct 29, 2008 at 8:28 PM, Graham Leggett <[EMAIL PROTECTED]> wrote:

> Paul Querna wrote:
>
>  One of the things I would like to do on the Simple MPM is unify how child
>> processes are created on win32 and unix.
>>
>> On Win32, there is no fork, so roughly speaking what the current winnt MPM
>> creates a new process, and feeds the configuration over a pipe to the new
>> child.
>>
>> On Unix, all of the current MPMs use fork, and do not execute a new
>> process, but instead then drop privileges and continue running.
>>
>> What I would like to do, is change Unix to use the same pattern as on
>> Windows.
>>
>
> Hmmm.
>
> I think for a large configurations, the copy on write is a significant
> optimisation - you can have large numbers of processes, and a large
> configuration, and get away with it, as practically the configuration is
> only memory resident once.
>
> I think it would be important to still support both, but certainly the code
> to support both shouldn't be at all complex. Perhaps the choice of which to
> choose could be configurable, so that Leopard users could choose "config via
> pipe".
>

If you are going to implement both methodes...
fork() should be used and exec and pipe the config as a fallback.

Then I know nothing about mpm's so I'll keep quite now.


>
> Although the MPM should be simple, it should ideally not be so simplified
> to become simplistic.
>
> Regards,
> Graham
> --


~ Jorge

Re: [VOTE] Release Apache HTTP server 2.2.10

[Jorge Schrauwen]

Running stable in a production environment here.
Haven't notice any problems

+1

Jorge

Re: Apache httpd 2.2.10 test tarballs available...

[Jorge Schrauwen]

Running fine for 1 day on gentoo.
Can't test on windows due to having no machine available.

~Jorge


On Wed, Oct 8, 2008 at 3:33 PM, Eric Covener <[EMAIL PROTECTED]> wrote:

> On Wed, Oct 8, 2008 at 9:17 AM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 10/07/2008 08:37 PM, Jim Jagielski wrote:
> >> ... at the usual location:
> >>
> >> http://httpd.apache.org/dev/dist/
> >>
> >> The availability of these test tarballs does not constitute
> >> an official release, however please download and test
> >> as a VOTE will be called for in the next few days regarding
> >> their release.
> >
>
> +1
>
> sles9/s390 (31-bit) all tests pass
> sles9/ppc (32-bit) all tests pass
> solaris 10/amd64 (64-bit, sun studio) all tests pass
>
> --
> Eric Covener
> [EMAIL PROTECTED]
>

Building minimal (static) httpd

[Jorge Schrauwen]

Hi

There was a discussion on IRC on building minimal static httpd to reduce
memory footprint.

You need a lot of --disable-xyz to do this. Would it be a lot of work to
include something like --minimal-static ?
This may also cater to people who want a simple webserver that only does
some static things. It could be build without much hassle.

If nobody has time for this could someone provide some tips on where I
should look to create a patch myself? So I can submit it (once I find time)?

Kind regards


~Jorge

Re: [community] 2.3.0 alpha on October 1?

[Jorge Schrauwen]

On Sun, Sep 14, 2008 at 10:09 AM, Bing Swen <[EMAIL PROTECTED]> wrote:

> William A. Rowe, Jr. wrote on 2008年8月22日 9:03:
>
>> Which brings me to the other half of [community], I'm proposing we hold
>> an Apache httpd {next} barcamp session for the community who are at
>> ApacheCon BarCamp on Tuesday to learn about what has changed, what might
>> change, and perhaps if we get enough folks to express interest ... about
>> what they want to change.
>>
>
> Another related question: We haven't been able to build httpd on 64-bit
> Windows for about two and half years, since the April 2006 release of
> httpd-2.2.2 (But x64 build is crucial for our application, and that's why we
> are still using that "aged version"). Shall we have 64-bit Windows release
> in the near future, say 2.2.10? (btw, we are really delighted to see that
> now APR has a *clean* compile on x64 Windows.)
>
> Bing
> 


This is no true. The latest version I've been able to compile was 2.2.9
http://www.blackdot.be/?inc=apache/binaries

You are however correct that it's getting more cumbersome! Vista + VS
2005/2008 is a no go. I'm using a XP x64 with VS 2005 in vmware to build it
now. Also command line building is busted Using the IDE it's still possible.

Jorge


>
> School of EE & CS,
> Peking University,
> Beijing 100871
>
>

Re: Dropping mod_sed into /trunk/ ?

[Jorge Schrauwen]

On Thu, Aug 21, 2008 at 1:53 PM, Jeff Trawick <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew <[EMAIL PROTECTED]> wrote:
>
>>
>> Any thoughts on dropping it in to trunk
>
>
> Is it best to preserve the current files/filenames (sed.h, libsed.h,
> sed0.c, etc.) to better reflect the history of that code, or should the
> files be combined/renamed to something that makes more sense for an Apache
> module that shares space with a lot of other modules?  (I'm assuming this
> goes into modules/filters and not its own modules/sed.)
>
>
>
Renaming them to fit better in for the apache file tree seems a good idea.
If its not done it will probably get done at some point in the future
anyway.

~Jorge

Re: SNI in 2.2.x (Re: Time for 2.2.10?)

[Jorge Schrauwen]

I like the idea of using --with-SNI and labeling it as experimental.
Maybe leave it of by default though?

~ Jorge


On Wed, Aug 20, 2008 at 1:10 PM, Nick Kew <[EMAIL PROTECTED]> wrote:

> On Wed, 20 Aug 2008 12:06:33 +0200
> Oden Eriksson <[EMAIL PROTECTED]> wrote:
>
> > FYI: This patch is applied in Mandriva Linux.
>
> Any feedback?  Bug reports coming from their users?
>
> If you'd said Debuntu or Deadrat+family, we might infer a user
> community big enough to rely on (FSreasonableVO rely).
> Not sure about Mandriva, but it's surely better than nothing.
>
> It seems clear that users *really* want it.  I'd say that adds
> weight to the argument for including it and taking the risk.
> It might be worth a --with-SNI configuration option, which
> would label it as an experimental feature.
>
> --
> Nick Kew
>

Re: WebDav MOVE/COPY between servers

[Jorge Schrauwen]

Hi,

Something like FXP (for ftp server) for WebDav would indeed be nice.

Although if you are looking to syncronize servers (not sure you are though)
rsync may be a better way.

Jorge

On 7/2/08, Rafa%u0142 <[EMAIL PROTECTED]> wrote:
>
> > I imagine most will allow copying to and from local file systems... so
> you
> > on your way.
>
> My purpose is to get rid of it in some cases. For example: I have my
> client system, and 2 webdav servers (dav1, dav2). I want to be able to
> copy/move files between dav1 and dav2 without copying them first to my
> client system. And I want to do it by Webdav commands, not by adding
> some other programs to servers.
>
> Best regards
>   Rafał Malinowski
>
> 
> Przedstawienie MEWA w wykonaniu Sanktpetersburskiego Teatru Baletu
> Borisa Ejfmana 17 lipca, godz.20:30 Opera Leśna-Sopot.
> Czytaj więcej
> http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Feifman.html&sid=401
>
>
>


-- 
~Jorge

Re: [VOTE] initial release of httpd-mod_ftp-0.9.0

[Jorge Schrauwen]

Compiles fine and is working as before on gentoo...
named vhosting still broken though

[ X ] +1 to release as 0.9.2-beta

~Jorge

On Sat, Jun 21, 2008 at 9:17 AM, Takashi Sato <[EMAIL PROTECTED]> wrote:

> On Tue, 17 Jun 2008 16:43:14 -0500
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
>
> >[ ] -1 for any release of 0.9.2
> >[ ] +1 to release as 0.9.2-alpha
> >[ ] +1 to release as 0.9.2-beta
> >[ ] +1 to release as 0.9.2-beta, and ready to tag GA (1.0.0)
>
> -0
>
> ftp_commands.c: In function 'ftp_cmd_pbsz':
> ftp_commands.c:1706: warning: comparison is always false due to limited
> range of data type
>
> If 'arg' is "2147483647"
> on the sizeof(int) == 4 == sizeof(long)  system,
> fc->pbsz == LONG_MAX.
> But on the sizeof(int) == 4 < sizeof(long) system,
> fc->pbsz != LONG_MAX.
>
> I have not read the code deeply, but I think this is not quite dangerous.
> There is no code using pbsz.
> I have found other assignments of resutl of strtol to int.
>
> mod_ftp.c line 406
> *(int *) ((char *) fsc + offset) = strtol(arg, &endptr, 10);
> line 436
> umask = strtol(arg, &endp, 8);
> line 459
> umask = strtol(arg, &endp, 8);
>
> My environment:
> FreeBSD 7-STABLE AMD64
> gcc version 4.2.1 20070719  [FreeBSD]
>

Re: [VOTE] initial release of httpd-mod_ftp-0.9.0

[Jorge Schrauwen]

Oops hit ctrl+s :/
...
I haven't given the latest source a spin (due to time problems with exams).
Last one I played with seemed to work reasonably well as a single server.

named vhost was broken though (wrowe: how is that coming along? can I give
that another run for its money later this week?)

If around the same state as when I was messing with it I'd say +1 for
beta... it was usable at least as single server. (was using it with FlashFXP
to mess around with it)
I'm not sure how it will cope with heavy usage though.

~Jorge

On Wed, Jun 18, 2008 at 10:23 AM, Jorge Schrauwen <[EMAIL PROTECTED]>
wrote:

> I haven't given the latest source a spin (due to time problems with exams).
> Last one I played with seemed to work reasonably well as a single server.
>
> named vhost was broken though (wrowe: how is that coming along? can I give
> that another run for its money later this week?)
>
> If around the same state as when I was messing with it I'd say +1 for
> beta... it was usable atleast as
>
> ~Jorge
>
> On Tue, Jun 17, 2008 at 11:43 PM, William A. Rowe, Jr. <
> [EMAIL PROTECTED]> wrote:
>
>> mod_ftp fans;
>>
>> We seem to have identified and solved most post 0.9.1 candidate issues,
>> so it's time for another try.
>>
>> Please fetch up the newly prepared httpd-mod_ftp-0.9.2.tar.gz (available
>> now), or the win32/netware/os2 suitable package
>> httpd-mod_ftp-0.9.2-crlf.zip (still needs to sync in the next hour) from:
>>
>>  http://httpd.apache.org/dev/dist/mod_ftp/
>>
>> review, take it for a spin, and cast your choice
>>
>>  [ ] -1 for any release of 0.9.2
>>  [ ] +1 to release as 0.9.2-alpha
>>  [ ] +1 to release as 0.9.2-beta
>>  [ ] +1 to release as 0.9.2-beta, and ready to tag GA (1.0.0)
>>
>> See http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.2/STATUS-FTP
>> identifying several issues (I don't plan to vote for better than -beta
>> just yet).  Supporting -beta means +1 to -alpha instead if that's the
>> majority opinion.
>>
>> For getting started,
>>
>> http://httpd.apache.org/mod_ftp/
>>
>> and
>>
>> http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.2/README-FTP
>>
>> Bill
>>
>>
>>
>>
>>
>

Re: [VOTE] initial release of httpd-mod_ftp-0.9.0

[Jorge Schrauwen]

I haven't given the latest source a spin (due to time problems with exams).
Last one I played with seemed to work reasonably well as a single server.

named vhost was broken though (wrowe: how is that coming along? can I give
that another run for its money later this week?)

If around the same state as when I was messing with it I'd say +1 for
beta... it was usable atleast as

~Jorge

On Tue, Jun 17, 2008 at 11:43 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]>
wrote:

> mod_ftp fans;
>
> We seem to have identified and solved most post 0.9.1 candidate issues,
> so it's time for another try.
>
> Please fetch up the newly prepared httpd-mod_ftp-0.9.2.tar.gz (available
> now), or the win32/netware/os2 suitable package
> httpd-mod_ftp-0.9.2-crlf.zip (still needs to sync in the next hour) from:
>
>  http://httpd.apache.org/dev/dist/mod_ftp/
>
> review, take it for a spin, and cast your choice
>
>  [ ] -1 for any release of 0.9.2
>  [ ] +1 to release as 0.9.2-alpha
>  [ ] +1 to release as 0.9.2-beta
>  [ ] +1 to release as 0.9.2-beta, and ready to tag GA (1.0.0)
>
> See http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.2/STATUS-FTP
> identifying several issues (I don't plan to vote for better than -beta
> just yet).  Supporting -beta means +1 to -alpha instead if that's the
> majority opinion.
>
> For getting started,
>
> http://httpd.apache.org/mod_ftp/
>
> and
>
> http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.2/README-FTP
>
> Bill
>
>
>
>
>

Re: [RESULT] (Was: Re: [VOTE] Release Apache HTTP Server 2.2.9)

[Jorge Schrauwen]

On Fri, Jun 13, 2008 at 9:58 PM, Joshua Slive <[EMAIL PROTECTED]> wrote:

> On Fri, Jun 13, 2008 at 3:49 PM, Jorge Schrauwen
> <[EMAIL PROTECTED]> wrote:
> > I'd say tomorrow so most mirrors will be synced by then... unless they
> sync
> > very fast... no idea how fast that is.
>
> You can see a histogram of last-sync times near the bottom of this page:
> http://www.apache.org/mirrors/
> Most mirrors sync at least every 12 hours and essentially all sync
> within 24 hours.
>

Oh I never noticed that.

Knowing this I'd still answer the question the same... wait for tomorrow.
No that it matters much what I think ^^ but every opinion seems to count so
I'll voice it anyway.

~Jorge

Re: [RESULT] (Was: Re: [VOTE] Release Apache HTTP Server 2.2.9)

[Jorge Schrauwen]

I'd say tomorrow so most mirrors will be synced by then... unless they sync
very fast... no idea how fast that is.

~Jorge

On Fri, Jun 13, 2008 at 9:12 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote:

> The tarballs and site files are being pushed to the mirrors...
>
> Announce tonight or tomorrow??
>

Re: in test framework

[Jorge Schrauwen]

To my knowledge default is a catch all kind of thing when done non
namedhosting.

vhost _default_:80
vhost localhost:80
vhost apache.org:80

if the server gets a host header of example.com it goes to _default_...
alteast that is how I understood it... not sure if thats documented
somewhere though. I got that from trial and error

~Jorge

On Wed, Jun 11, 2008 at 11:33 PM, Nick Kew <[EMAIL PROTECTED]> wrote:

> Line 367 in t/conf/httpd.conf reads:
>
> 
>
> This causes a failure on Solaris, with
>  Could not resolve address '255.255.255.255' -- check resolver
>  configuration.
> The same thing happens in various other places in the test
> suite's config.
>
> Is _default_ supposed to do anything meaningful?
>
> Trying with localhost instead, I just got
>
> Failed TestStat Wstat Total Fail  Failed  List of Failed
>
> ---
> t/security/CVE-2004-0959.t2   512??   ??   %  ??
> t/security/CVE-2008-2364.t31  33.33%  3
>
> Investigating those.
>
> --
> Nick Kew
>
> Application Development with Apache - the Apache Modules Book
> http://www.apachetutor.org/
>

Re: [VOTE] Release Apache HTTP Server 2.2.9

[Jorge Schrauwen]

Ok did a new build with openssl on vs 2008 on vista.
It still give me hell over ipv6... there is a patch that fixes it!
https://issues.apache.org/bugzilla/attachment.cgi?id=21320&action=edit

with this patch it works fine following the basic steps of converting the
source (lineends.pl), perl cvtdsp.pl -2005
devenv Apache.dsw (to get command line building to work with vs2008)

for that point on it compiles fine from command line.

I've placed my binaries here for anyone that wants to do some heavier
testing on them (will be gone tomorrow):
*http://cygnus.gotdns.org/ (note: pdb's are included - very slow upload...
home server)*

I only tested the out of box config.

Jorge

On Wed, Jun 11, 2008 at 10:08 AM, Jorge Schrauwen <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Jun 11, 2008 at 9:16 AM, Issac Goldstand <[EMAIL PROTECTED]>
> wrote:
>
>>
>>
>> Jim Jagielski wrote:
>>
>>> Test tarballs for Apache httpd 2.2.9 are available at:
>>>
>>>http://httpd.apache.org/dev/dist/
>>>
>>> Your votes please;
>>>
>>>  +/-1
>>>  [  ]  Release httpd-2.2.9 as GA
>>>
>>> 
>>>
>>>  +1 Tested prefork + worker on linux with no problems.  If I get a chance
>> to test win32 before the vote closes, I will, but based on Jorge's tests +
>> Bill's satisfaction with win32, I'm happy as long as noone -1s it.
>>
>
> I did have some problems with using vs 2008... I had to grab back to 2005.
> I'll give it a spin with ssl later this evening if I got time.
>
>
>>
>>  Issac
>>
>
>
>
> --
> ~Jorge




-- 
~Jorge

Re: [VOTE] Release Apache HTTP Server 2.2.9

[Jorge Schrauwen]

On Wed, Jun 11, 2008 at 9:16 AM, Issac Goldstand <[EMAIL PROTECTED]>
wrote:

>
>
> Jim Jagielski wrote:
>
>> Test tarballs for Apache httpd 2.2.9 are available at:
>>
>>http://httpd.apache.org/dev/dist/
>>
>> Your votes please;
>>
>>  +/-1
>>  [  ]  Release httpd-2.2.9 as GA
>>
>> 
>>
>>  +1 Tested prefork + worker on linux with no problems.  If I get a chance
> to test win32 before the vote closes, I will, but based on Jorge's tests +
> Bill's satisfaction with win32, I'm happy as long as noone -1s it.
>

I did have some problems with using vs 2008... I had to grab back to 2005.
I'll give it a spin with ssl later this evening if I got time.


>
>  Issac
>



-- 
~Jorge

Re: [VOTE] Release Apache HTTP Server 2.2.9

[Jorge Schrauwen]

On Wed, Jun 11, 2008 at 5:22 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]>
wrote:

> Jim Jagielski wrote:
>
>> Your votes please;
>>
>>  +/-1
>>  [+1]  Release httpd-2.2.9 as GA
>>
>
> I'll rely on others to review linux, solaris, et al, but based on Win32 I'm
> very happy and just waiting for feedback from my prior questions to post up
> the various files.
>

Yes, windows seems fine... didn't test with ssl though.

-- 
~Jorge

Re: Tagging 2.2.9...

[Jorge Schrauwen]

Will try to test it tomorrow... win or linux? I can do both but will only
have time to give it a quick peak on one (exames)

On Tue, Jun 10, 2008 at 10:33 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote:

> Still waiting for the sync... I had thought it was every hour... :/
>
>
> On Jun 10, 2008, at 3:29 PM, Jim Jagielski wrote:
>
>  2.2.9 is tagged and rolled... Once www syncs with people, I'll
>> provide the URL and start the voting
>>
>> On Jun 10, 2008, at 1:44 PM, Jim Jagielski wrote:
>>
>>  I am tagging 2.2.9 in 1-2 hours...
>>>
>>>
>>
>


-- 
~Jorge

VirtualHostMysql no hosted on google code... wiki safe?

[Jorge Schrauwen]

Hi docs and dev list,

In follow up to http://www.gossamer-threads.com/lists/apache/docs/350946

I posted this on the docs list:
http://www.gossamer-threads.com/lists/apache/docs/351355

I still haven't gotten a reply or comments on this. Since its been quite a
while I though i'd post it again and hopefull this time somebody will reply.

Kind regards

Jorge Schrauwen (sjorge on #apache)

Re: 2.2.9

[Jorge Schrauwen]

On Tue, May 6, 2008 at 4:36 PM, Plüm, Rüdiger, VF-Group <
[EMAIL PROTECTED]> wrote:

>
>
> > -Ursprüngliche Nachricht-
> > Von: Jim Jagielski
> > Gesendet: Dienstag, 6. Mai 2008 15:51
> > An: dev@httpd.apache.org
> > Betreff: Re: 2.2.9
> >
> > I'm back from a few days away and offline, and like to get
> > the momentum for 2.2.9 back up.
> >
> > 2 main things:
> >
> > 1. There are a number of backport proposals looking
> >for and waiting for a 3rd +1... if you have time
> >to look/review/vote, that would be good.
> >
> > 2. Consensus on whether we ship with APR 1.2.x or 1.3.x...
> >My pref would be 1.3.
>
> Ship with 1.3, but do not make it depend on 1.3 yet. This makes it
> easy to swap in 1.2.x again if it turns out that there is something
> nasty in 1.3. We can can make it dependant on 1.3 in 2.2.10 or 2.2.11
> depending on our experience.
>
> Regards
>
> Rüdiger
>

I really like this proposal (my non counting +1 on this)

-- 
~Jorge

Re: Apache 3.0

[Jorge Schrauwen]

Just out of curiosity... will 3.0 still be a fresh start or will the
core of 2.3 be used?

On Sun, Apr 13, 2008 at 8:31 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> On Apr 12, 2008, at 7:10 PM, Paul Querna wrote:
>
> > For those who were not there, slides from Roy's keynote at ApacheCon EU:
> >  
> >
>
>  heh, good thing I managed to get the Internet connection to work long
> enough
>  for the upload.
>
>
>
> > The only reply I can really come up with is:
> >
> >  Patches Welcome.
> >
>
>  Patches? We don't need no stinkin' patches.
>
>
>
> > I don't agree with, or disagree with all of the topics Roy discusses, and
> I do think we should focus more on 'fun' things, but I'm not sure we have an
> active enough community to really toss everything out, and plunge head first
> into a 3.0 development sprint.
> >
>
>  We don't have to.  The point is that we should stop worrying about what
>  we have the time to do and just let whoever does have the time to do,
>  just do, in a way that we can make use of it when we do have the time.
>  If the result isn't worth adopting, then we don't adopt it as Apache 3.
>
>  We can steer the project wherever the majority want to go, but someone
>  has to provide the wheels.
>
>  Roy
>



-- 
~Jorge

Re: Apache 3.0

[Jorge Schrauwen]

The slide showing the protocols httpd supports is kind of dead on.

Personaly I like it that I'm able to serve http, ftp,... with one
server package.

If this is they way to go I think in 3.0 a entire new design would
benifit and remove a lot of workaround in forcing the protocols to
work with the httpd core.
Although then it can no longer be httpd but apached or something in the like.

Although dropping back to waka/http is an other options but I think
some users will be dissapointed.
Why run 4 different daemons while one will do? (ok I can think of a
lot of reasons but I can think of some no to do it either.)

Just my 2 cents

Jorge

On Sat, Apr 12, 2008 at 7:10 PM, Paul Querna <[EMAIL PROTECTED]> wrote:
> For those who were not there, slides from Roy's keynote at ApacheCon EU:
>   
>
>  The only reply I can really come up with is:
>
>   Patches Welcome.
>
>  I don't agree with, or disagree with all of the topics Roy discusses, and I
> do think we should focus more on 'fun' things, but I'm not sure we have an
> active enough community to really toss everything out, and plunge head first
> into a 3.0 development sprint.
>
>  -Paul
>
>



-- 
~Jorge

Re: Apache -MySQL module ??

[Jorge Schrauwen]

You can allready do that using mod_perl.
It's not exactly what you are looking for but its a nice start:
http://wiki.apache.org/httpd/ApacheVirtualHostMysql

Jorge

On Tue, Apr 8, 2008 at 2:45 PM, Agnello George <[EMAIL PROTECTED]> wrote:
> Hi
>  I would like to know if any one has worked on Apache -MySQL module
>  Just like bind-dlz , i would like to know if it is possible of
>  instead of storing the location of the website directory path in files
>  could it be stored in a MySQL database. And if possible how do i query
>  to that database through  the httpd.conf file .
>
>  Thank you
>
>  Awaiting your reply
>  --
>  Regards
>  Agnello Dsouza
>



-- 
~Jorge

Re: mod_ftp trunk

[Jorge Schrauwen]

Thanks tom, I'll give that a swirl later today or tomorrow depending
on when I have time.

On Tue, Apr 8, 2008 at 4:38 AM, Tom Donovan <[EMAIL PROTECTED]> wrote:
> Whoops!  I forgot - there's one more bug - 44653, for a total of three bugs.
>
>  Making these 3 changes should let you build mod_ftp trunk to use with httpd
> trunk.
>
>  If you are building mod_ftp to use with httpd 2.2, you only need to fix
> 44653.
>
>  -tom-
>
>
>
>  Tom Donovan wrote:
>
> > Jorge Schrauwen wrote:
> >
> > > I'l actually not sure if mod_ftp has a separate list... so I'll send it
> here.
> > > On the page it says to fetch the trunk and build it.
> > >
> > > But the trunk doesn't build!
> > >
> > > Adding a message saying it won't build or maybe keep a prelease branch
> > > that does compile and work on trunk so there is a working or atleast
> > > compiling version availble.
> > >
> > >
> > >
> > I entered two minor bugs & proposed patches for mod_ftp (trunk) last week
> - see bugs 44746 & 44747.
> >
> > mod_ftp trunk builds & runs OK for me on Windows with these changes.
> >
> > -tom-
> >
> >
>
>



-- 
~Jorge

mod_ftp trunk

[Jorge Schrauwen]

I'l actually not sure if mod_ftp has a separate list... so I'll send it here.
On the page it says to fetch the trunk and build it.

But the trunk doesn't build!

Adding a message saying it won't build or maybe keep a prelease branch
that does compile and work on trunk so there is a working or atleast
compiling version availble.


-- 
~Jorge

Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])

[Jorge Schrauwen]

On Thu, Apr 3, 2008 at 4:31 PM, Mads Toftum <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote:
>  > Time for a 2.4 release? I wouldn't mind pushing that along
>  > and get some of the feature-set of 2.4 out before we do too
>  > much ripping with the inevitable delays associated with that :)
>
>  Is there really enough news in trunk to warrant the overhead of
>  maintaining yet another branch? tbh. I'd much rather see work going
>  towards 3.x ;)
>
>  vh
>
>  Mads Toftum
>  --
>  http://soulfood.dk
>

I'm wondering the same.


-- 
~Jorge

Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]

[Jorge Schrauwen]

>  ... if we had a config finalize, modules who were prepared to declare
>  their config (e.g. mod_vhost declaring the per-host directory merges
>  "completed") then as-root, we can finish these out, opening logs with
>  full privileges.  Other merges will happen at run time (or be optimized
>  when we can accomplish this) per-request.

So does a setup like this make it possible for the processes/thread
handling the request to change to the correct UID/GID before
reading/writing files? Just something that popped into my head when
reading this.

-- 
~Jorge

Re: Dynamic configuration for the hackathon?

[Jorge Schrauwen]

On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand <[EMAIL PROTECTED]> wrote:
>
>
>
>  Jorge Schrauwen wrote:
>  > Solutions propose:
>  > - lua in the core or atleast in a module
>  > - mod_perl
>
>  mod_perl exists already.  We're looking to replace it because... (see below)
>

I'm quite aware that it exists, I ment that it is a possible solution
to the problem.
(I'm actually using it... although restarts are still needed to load
the new vhosts)

>
>  >
>  > Downside:
>  > - perl isn't very easy and userfriendly
>
>  I think that the downside is the fact that perl interpreters suck up
>  RAM, not the easiness factor.  It's probably not significantly
>  easier/harder than lua, but it's big and clunky
>

Well perl did scare the *bleep* out of my class mates when they where
looking what I was doing during the break.
Then again, I do most of my system scripts in perl ^^

>Issac
>
>



-- 
~Jorge

Re: Dynamic configuration for the hackathon?

[Jorge Schrauwen]

Let me try and summarize this then:

Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
Where they can configure things on a request basis and add vhosts and
such without restarting httpd.

Solutions propose:
- lua in the core or atleast in a module
- mod_perl

Downside:
- perl isn't very easy and userfriendly
- overhead of having this be re-evaluated a lot
- lue -> users to lazy to learn new language

I'm sure I missed a lot since I seem to be missing some older messages
so feel free to ignore this add to it or whatever.

-- 
~Jorge

Re: Dynamic configuration for the hackathon?

[Jorge Schrauwen]

I used to use mod_macro, then I moved to mod_perl but like you said.
mod_perl is great (well, more okay than great) for dynamic configurations
that change/get generated on start and not per request.

A new more flexible alternative would be awsome.

Jorge (on vacation)

On Thu, Mar 27, 2008 at 8:58 AM, Torsten Foertsch <[EMAIL PROTECTED]>
wrote:

> On Wed 26 Mar 2008, Akins, Brian wrote:
> > > There seems to be a demand for dynamic per-request configuration,
> > > as evidenced by the number of users hacking it with mod_rewrite,
> > > and the other very limited tools available.  Modern mod_rewrite
> > > usage commonly looks like programming, but it's not designed as
> > > a programming language.  Result: confused and frustrated users.
> >
> > This is what I had in mind when I suggested having  blocks of code.
> >  No need to invent a new language when a perfectly fine one exists...
>
> As Issac pointed out something similar can be done with  blocks at
> the
> cost of having mod_perl in core. Those are not evaluated evaluated
> per-request.
>
> But based on mod_perl there is Apache2::Translation that does per-request
> configuration. It hooks uri translation, maptostorage and fixup to do the
> job. Again it needs a perl interpreter in core and hence doesn't work well
> with threaded MPMs. So I was going to reimplement it based on mod_wombat
> some
> time this year.
>
> I just wanted to add these $0.02 to the discussion.
>
> Torsten
>



-- 
~Jorge

Re: Experience with Visual Studio 2008 Professional Edition

[Jorge Schrauwen]

I've had no problems building with VC9 either, unless you do it on vista
since the new PSDK updates some files and a small edit is needed.

Also x64 building is out of the question for some reason OpenSSL/Zlib nor
httpd itself want to compile at all.

On Wed, Mar 5, 2008 at 10:12 PM, Harry Holt <[EMAIL PROTECTED]> wrote:

> How about SSL over mod_ldap?
>
>
> On Wed, Mar 5, 2008 at 2:38 PM, Issac Goldstand <[EMAIL PROTECTED]>
> wrote:
>
> >
> > Steffen wrote:
> > > Just to inform you.
> > > We at Apache Lounge done the first build with  Visual Studio 2008
> > > Professional Edition.
> > >
> > > SDK 6.1 (latest as today)
> > > 2.2.8 source (plus dso and fix for DOS-box)
> > > Openssl was build with VC8
> > > Zlib was build with VC8
> > >
> > > Changed in apr.hw (otherwise errors):
> > >
> > > #define _WIN32_WINNT 0x0600
> > >
> > > Further no changes.
> > >
> > > IDE build goes fine with no errors.
> > >
> > > First impression:
> > > Apache runs fine on my XP box, including mod_ssl.
> > > Only mod_deflate was not loading. Rebuilding Zlib (ms-asm) with VC9
> > and
> > > then build mod_deflate again and it
> > > starts and works.
> > >
> > > Also all the modules build with VC8, like mod_security 2.5.0,
> > mod_watch,
> > > mod_fcgid, mod_vieuw are running.
> > >
> > >
> >
> > Cool!
> >
> >   Issac
> >
>
>
>
> --
> Harry Holt, PMP




-- 
~Jorge

Re: ping on mod_dns

[Jorge Schrauwen]

true but like Roy said if mod_dns is allready in use a new name will
need to be found no?

On Feb 18, 2008 8:42 PM, Issac Goldstand <[EMAIL PROTECTED]> wrote:
>
>
>
> Jorge Schrauwen wrote:
> > If the mod_dns mentioned before is different from the code... may I
> > sugest mod_named? since a lot of people would be famileir with a name
> > like htat.
>
> True, but that would break naming conventions:
>
> mod_smtp
> mod_ftp
> (mod_proxy_ajp, mod_proxy_http, mod_proxy_ftp)
> and even the included http module that handles http...
>
> -0
>
>Issac
>



-- 
~Jorge

Re: ping on mod_dns

[Jorge Schrauwen]

If the mod_dns mentioned before is different from the code... may I
sugest mod_named? since a lot of people would be famileir with a name
like htat.

On Feb 18, 2008 8:22 PM, Erik Abele <[EMAIL PROTECTED]> wrote:
> On 18.02.2008, at 20:03, Roy T. Fielding wrote:
>
> > On Feb 9, 2008, at 4:21 PM, Issac Goldstand wrote:
> >
> >> Any volunteers to import mod_dns so I can eventually start hacking
> >> at it
> >> again (topic came up at work recently and I have a couple of feature
> >> ideas that I'd like to work on, but really don't want to have to
> >> work in
> >> my old svn + port changes to asf svn too)?
> >>
> >> AFAIK, we finished with the red tape already (please tell me off-
> >> list if
> >> I'm wrong)
> >
> > Actually, I'd rather do that on-list so that more people know what is
> > required.  We already had the proposal and enough +1 votes to add
> > mod_dns as a subproject.
> >
> >   http://markmail.org/message/juhrpyxq635mhy6n
> >
> > The next question is about the intellectual property.
> > ...
>
> See also the thread 'Issac Goldstand / mod_dns' on board@ for some
> info re paper-work (02/10/2008)...
>
> Cheers,
> Erik
>



-- 
~Jorge

Re: ping on mod_dns

[Jorge Schrauwen]

Me too, If this gets in experimental I'll probably give it a try
sounds really interesting

On Feb 10, 2008 2:16 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote:
>
> On Feb 10, 2008, at 1:21 AM, Issac Goldstand wrote:
>
> > Any volunteers to import mod_dns so I can eventually start hacking
> > at it
> > again (topic came up at work recently and I have a couple of feature
> > ideas that I'd like to work on, but really don't want to have to
> > work in
> > my old svn + port changes to asf svn too)?
>
>
> I'd be quite interested to see this go in as 'experimental' or similar.
>
> Dw.
>



-- 
~Jorge

Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8

[Jorge Schrauwen]

On 1/11/08, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Jorge Schrauwen wrote:
> >
> > libaprutil is still set to x64 instead of win32 when compiling under
> > 2008 but I take this will get fixed in the win32 src package
>
> No; you set it; that is to say that visual studio is bugged, and VC6
> .dsw did not specify per-project dependencies, VS .sln migration makes
> foolish associations.  This is even true when I introduce x64 targets
> to all projects, it has nothing to do with the source .dsw/.dsp files.
> You need to update these; there may be a separate package that offers
> .sln's at some point to fix VS bugs, haven't decided.  (The src package
> is intended to be built from exported .mak files).
>
> > multicast.c is still broken using vs 2008 with the latest platform
> > SDK, vs 2005 with the older platform SDK works fine! (there is a patch
> > for this... IIRC its also in apr trunk but it was laten when I was
> > talking about this with wrowe I can't remember for certain)
>
> It's also on apr branches but not yet released;
> https://issues.apache.org/bugzilla/show_bug.cgi?id=40398
>
> the patch applied to apr was the Cleaner and not Dirtier flavor.
>
> It will hit the next 1.2.x apr release, I'd presume there will be one
> sooner or later.
>
> > FWIW: BuildBin's installdir is still set to /apache2 instead of
> > /apache22 not that will effect anything just something I noticed.
>
> Yup - no impact, not likely to change.
>
> > The /machine not set warnings are still there aswel but again no
> > problem here since it defaults to x86
>
> or defaults to x64 using that compiler/linker.  Again, goofy win32
> behaviors, and can't be fixed without x64 + win32 (x86) targets which
> would permit compilation using two-different targets.
>
> It was more than I wanted to mess with for this point bump, but will
> probably get back to that issue over the next several weeks.
>
>

I'd be willing to generate and package vs 2008 sln and fix the
apr-util goofyness.
Say if  solution files are created... do we want different packages
for 2005, 2008,...?

2008 is said to be compatible with 2005 but opening a 2005 sln in 2008
it still randomly changes settings and such.

Say if I create such a extended package based on the office 2.2.8
win32 src do you think that could be useful? I can always place it on
my own website for interested people but I suspect it won't get much
attention there and won't be worth the hassle.

-- 
~Jorge

Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8

[Jorge Schrauwen]

  []   Apache HTTP Server 1.3.41
  []   Apache HTTP Server 2.0.63
  [+1]   Apache HTTP Server 2.2.8 (win32 + mac)


-- 
~Jorge

Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8

[Jorge Schrauwen]

+1 on win32 for me if I could vote

libaprutil is still set to x64 instead of win32 when compiling under
2008 but I take this will get fixed in the win32 src package
multicast.c is still broken using vs 2008 with the latest platform
SDK, vs 2005 with the older platform SDK works fine! (there is a patch
for this... IIRC its also in apr trunk but it was laten when I was
talking about this with wrowe I can't remember for certain)

FWIW: BuildBin's installdir is still set to /apache2 instead of
/apache22 not that will effect anything just something I noticed.
The /machine not set warnings are still there aswel but again no
problem here since it defaults to x86

modules compiled and working:
- mod_perl
- mod_macro
- mod_fcgid
- mod_ftp (compiles not tested)


Jorge


On Jan 11, 2008 5:33 AM, Paul Querna <[EMAIL PROTECTED]> wrote:
>
> Jim Jagielski wrote:
> > Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63
> > and 2.2.8 are available for download and test at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> > Their availability does not constitute an official release.
> > However, please download and test. I will be calling for
> > a release VOTE in the next 24-48 hours, at most.
>
>
> eos.apache.org and aurora.apache.org, the machines that host
> www.apache.org, and most TLPs, have both been upgraded to 2.2.8:
> http://www.apache.org/server-status
>
> They are also now running with the Event MPM, previously the Worker MPM
> was used.
>
> I used an APR and APR-Util snapshot, from their respective trunks, due
> to issues with mod_mbox performance, that have been fixed in apr-util
> trunk[1].
>
> Both machines are Solaris 10/SPARC, and I ran into no major issues
> getting it all working.  If you notice any issues with any apache.org
> sites, please let me know :-)
>
> Thanks,
>
> -Paul
>
> [1] - http://svn.apache.org/viewvc?view=rev&revision=513046
>



-- 
~Jorge