Re: [PATCH] mod_ssl: improving session caching for SNI configurations

[Kaspar Brand]

Joe Orton wrote:
> 1) why do we need a new config directive for session ticket support?  
> I'm struggling to understand why any server admin would need/want 
> control over support for session tickets.

Session tickets are a relatively new thing (RFC 4507 is from May 2006),
and I'm not sure how well current TLS implementations interoperate with
each other. For situations like these, it seems desirable to me if the
admin can control this through a directive (it's not fundamentally
different form knobs like SSLHonorCipherOrder, SSLOptions
OptRenegotiate, SSLRenegBufferSize, and SSLStrictSNIVHostCheck, IMO).

> 2) I do not think we should be hacking around OpenSSL bugs as the code 
> for SSL_CTX_set_tlsext_ticket_keys() is.  People using buggy versions of 
> OpenSSL should upgrade to versions which are not buggy, if they are 
> affected.

OpenSSL versions 0.9.8f through 0.9.8l are probably going to stay around
for quite some time, so why not do these users a favor with a few
(conditionally compiled) lines? It could just be considered a special
case of OpenSSL "feature checking", like #ifdefs for
SSL_OP_CIPHER_SERVER_PREFERENCE or HAVE_SSL_X509V3_EXT_d2i (which are
quite common in mod_ssl).

> At most here I'd do as your original patch does, to set the 
> SSL_OP_NO_TICKET flag if no session cache is enabled.  This is 
> sufficient to fix the issue in question, right?

My original patch disabled tickets only if a session cache *is*
configured (nSessionCacheMode != SSL_SCMODE_NONE), because in that case,
session tickets really make sense - there's no stateful cache, so leave
support for stateless resumption enabled.

Turning off ticket support when no cache is configured seems like a bad
idea to me - it will fix the issue for clients based on OpenSSL <=
0.9.8l, true, but at the cost of making it impossible to run mod_ssl
with stateless resumption only (which I think is a perfectly legitimate
use case).

> 3) The MD5 hash used in the session id context is just a hash.  It has 
> no cryptographic use AFAIK and MD5 is a perfectly fine hash, so I don't 
> see any need to change that.

Correct, the question is how likely a collision of two vhost_ids
(servername:port) is with MD5. Changing to SHA-1 for trunk shouldn't
hurt, however - and might obviate future questions as to why mod_ssl
(still) uses MD5 internally.

Kaspar

Re: Httpd 3.0 or something else

[Graham Leggett]

William A. Rowe Jr. wrote:

>> - Supporting prefork as httpd does now; and
> 
> I'm very happy to see prefork die it's timely death.
> 
> Let's go about working out where out-of-process magic happens.
> Gated, single threaded handlers may be sensible in some cases.
> But for the core server it makes async worthless, and supporting
> both digs us deeper into the bad-old-days of the 1.3 codebase.

I disagree strongly, for a number of reasons.

The first is that in our experience of a very high traffic collection of
websites, the more "hops" you have, the more performance starts to suck,
with the added complication that you run the risk of bumping your head
into the ceiling of filehandle limits, and other issues.

If you move from "httpd-prefork" to "httpd-something proxied to
random-appserver-X-doing-prefork-for-you" you aren't removing prefork -
you just moving it somewhere else and adding an extra hop.

You're also making it more complicated, and more complicated means less
reliable.

People like to harp on about how they want "speed speed speed". Right up
to the point where it first starts becoming unreliable. At that point
they suddenly start crying "reliable reliable reliable".

Apache httpd does lots of things right.

We must resist the temptation to throw out what we do right, while we
try move forward fixing what we do wrong.

Regards,
Graham
--

Re: Httpd 3.0 or something else

[Bojan Smojver]

On Wed, 2009-11-11 at 13:09 +0200, Graham Leggett wrote:
> Apache httpd does lots of things right.
> 
> We must resist the temptation to throw out what we do right, while we
> try move forward fixing what we do wrong.

And there is also a reason why Google's Chome is essentially (pre)fork.
This model is simply unrivalled when it comes to reliability.

-- 
Bojan

Re: intend to roll 2.3 alpha on Wednesday

[Jim Jagielski]

On Nov 9, 2009, at 12:57 PM, Paul Querna wrote:

> Hello dev@,
> 
> I intend to roll a 2.3 alpha release on Wednesday November 11th.
> 

+1

> I will bundle APR from the 1.4.x branch. (APR people should make a
> release, but this shouldn't be a blocker for our own alpha releases).
> 

+1

> I am almost 90% sure the release might fail due to various issues, but
> we need to start cleaning those issues out.
> 

+1

Thx!

Re: Httpd 3.0 or something else

[Jim Jagielski]

On Nov 11, 2009, at 6:09 AM, Graham Leggett wrote:

> William A. Rowe Jr. wrote:
> 
>>> - Supporting prefork as httpd does now; and
>> 
>> I'm very happy to see prefork die it's timely death.
>> 
>> Let's go about working out where out-of-process magic happens.
>> Gated, single threaded handlers may be sensible in some cases.
>> But for the core server it makes async worthless, and supporting
>> both digs us deeper into the bad-old-days of the 1.3 codebase.
> 
> I disagree strongly, for a number of reasons.
> 
> The first is that in our experience of a very high traffic collection of
> websites, the more "hops" you have, the more performance starts to suck,
> with the added complication that you run the risk of bumping your head
> into the ceiling of filehandle limits, and other issues.
> 
> If you move from "httpd-prefork" to "httpd-something proxied to
> random-appserver-X-doing-prefork-for-you" you aren't removing prefork -
> you just moving it somewhere else and adding an extra hop.
> 
> You're also making it more complicated, and more complicated means less
> reliable.
> 
> People like to harp on about how they want "speed speed speed". Right up
> to the point where it first starts becoming unreliable. At that point
> they suddenly start crying "reliable reliable reliable".
> 
> Apache httpd does lots of things right.
> 
> We must resist the temptation to throw out what we do right, while we
> try move forward fixing what we do wrong.
> 

I must say I agree. Having a method to avoid the 1:1 mapping of request/resp
to a specific "entity" (worker or thread) is nice, but that solves a
different problem than that solved by prefork. I'd like for us to solve
the one while also being able to continue to solve the other. When, for
example, nginx works, it works well. When it doesn't, it is simply
completely unsuitable. I'd like for us to continue to avoid that being
the case for httpd.

Re: svn commit: r834900 - in /httpd/mod_fcgid/trunk: Makefile.apxs configure.apxs

[Jeff Trawick]

On Wed, Nov 11, 2009 at 10:13 AM,   wrote:
> Author: trawick
> Date: Wed Nov 11 15:13:31 2009
> New Revision: 834900
>
> URL: http://svn.apache.org/viewvc?rev=834900&view=rev
> Log:
> Follow up the awk compatibility fix in r834729 by selecting the most
> suitable awk, following the AC_PROG_AWK order (gawk, mawk, nawk, awk).
> As with AC_PROG_AWK, AWK=foo overrides.
>
> After r834729 a working conf was generated on Solaris when using
> /usr/bin/awk, but only by some fluke of command-line processing
> (-v was sort-of ignored; see PR for discussion).  Also, the LoadModule
> wasn't added in the right spot due to awk engine differences.

Any comments on this before I integrate it into mod_ftp?

I know of at least one remaining ugly: on Solaris 10, the tests for
missing awks result in a couple of

xxx: not found

before it settles on nawk.  I didn't see how to squelch stderr with
/bin/sh, and I didn't want to follow AC_PROG_AWK's lead on parsing
PATH and checking for file existence in each PATH dir.

Re: Re: mod_fcgid: add mod_status support?

[pqf]

> 
> Jeff Trawick wrote:
> > 2009/11/9 pqf :
> >> Hi, all
> >>I am new to this community, I am think to add mod_status support to 
> >> mod_fcgid, which provide more internal information to administrators. Is 
> >> it a good idea? I am working on it now, but if someone think it's not a 
> >> good idea, please let me know.
> > 
> > Sure.  I'd like to see a view of processes and perhaps scores from 
> > mod_status.
> 
> I'd like to see this become an extensible mechansim.  It was on the topic list
> last week until SSL issues got the better of us.
> 
> I'll post thoughts in the coming week, Aaron, DougM and I have all done some
> pondering on this subject that would make things cleaner for all.
> 
> But in terms of 2.0/2.2 legacy fcgid support for scoreboard, Sander's comments
> are right on.

I just finished a version which scan share memory and print out FastCGI process 
status. just like mod_ssl does.
But will the mechansim be changed to an extensible one in the future? external 
modules like mod_ssl should
use another mechansim to do this? Look forward for further discussion in the 
next week :)

Re: Httpd 3.0 or something else

[Akins, Brian]

On 11/10/09 6:20 PM, "Greg Stein"  wrote:

> I'd like to see a few "network" threads multiplexing all the writing
> to clients. 

That's what I meant. I just didn't state it properly.

 
> Then take all of *that*, and spread it across several processes for
> solid uptime, with a master monitor process.

And then you have nginx ;)

-- 
Brian Akins

Re: Httpd 3.0 or something else

[Greg Stein]

On Wed, Nov 11, 2009 at 14:14, Akins, Brian  wrote:
> On 11/10/09 6:20 PM, "Greg Stein"  wrote:
>
>> I'd like to see a few "network" threads multiplexing all the writing
>> to clients.
>
> That's what I meant. I just didn't state it properly.
>
>
>> Then take all of *that*, and spread it across several processes for
>> solid uptime, with a master monitor process.
>
> And then you have nginx ;)

Right. But they don't have the depth/breadth of modules like we do. As
long as we can keep that ecosystem, then Apache will always be a
leader.

Cheers,
-g

[VOTE] release 2.3.3 as alpha

[Paul Querna]

Test tarballs for Apache httpd 2.3.3-alpha are available at:


Your votes please;

 +/- 1
 [  ]  Release httpd-2.3.3 as Alpha

Vote closes at 18:00 UTC on Sunday November 15 2009.

Thanks,

Paul

Re: intend to roll 2.3 alpha on Wednesday

[William A. Rowe Jr.]

Graham Leggett wrote:
> Paul Querna wrote:
> 
>> I intend to roll a 2.3 alpha release on Wednesday November 11th.

+1

>> I will bundle APR from the 1.4.x branch. (APR people should make a
>> release, but this shouldn't be a blocker for our own alpha releases).

Major problem; don't do this.  You are putting 1.4.x code into a release
which then ends up causing APR 1.4.0 to break its binary ABI rules.  That
is just not kosher.  Some README or release notes observing that the best
results can be obtained with a checkout and build of the as-yet-unreleased
apr 1.4.x trunk is sufficient.

If you want to 'test the bundling' - use a released apr please?

>> I am almost 90% sure the release might fail due to various issues, but
>> we need to start cleaning those issues out.

:)

> Is there a need to bundle APR at all?

Agreed +1 if APR is not bundled (this is alpha, after all).

Re: intend to roll 2.3 alpha on Wednesday

[Paul Querna]

On Wed, Nov 11, 2009 at 11:56 AM, William A. Rowe Jr.
 wrote:
> Graham Leggett wrote:
>> Paul Querna wrote:
>>
>>> I intend to roll a 2.3 alpha release on Wednesday November 11th.
>
> +1
>
>>> I will bundle APR from the 1.4.x branch. (APR people should make a
>>> release, but this shouldn't be a blocker for our own alpha releases).
>
> Major problem; don't do this.  You are putting 1.4.x code into a release
> which then ends up causing APR 1.4.0 to break its binary ABI rules.  That
> is just not kosher.  Some README or release notes observing that the best
> results can be obtained with a checkout and build of the as-yet-unreleased
> apr 1.4.x trunk is sufficient.
>
> If you want to 'test the bundling' - use a released apr please?

No released APR works.

Under our own versioning guidelines, we can and will break
compatibilty inside 2.3.x, so I don't see the issue created by using a
bundled APR.

>>> I am almost 90% sure the release might fail due to various issues, but
>>> we need to start cleaning those issues out.
>
> :)
>
>> Is there a need to bundle APR at all?
>
> Agreed +1 if APR is not bundled (this is alpha, after all).
>

If APR had a 1.4.0 released, it would be viable, but it doesn't.

Re: Httpd 3.0 or something else

[Arturo 'Buanzo' Busleiman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greg Stein wrote:
> Right. But they don't have the depth/breadth of modules like we do.

... yet. Keep going, but if there are great things like lighttpd and nginx (and 
even more) http
daemons out there, then that means more than one thing is wrong with current 
Apache.

Great thread.

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - OWASP - SANS - OISSG
http://www.buanzo.com.ar/pro/eng.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAkr7F+QACgkQAlpOsGhXcE2HbACcCgMwxXMnOJlAyyvfOTURgjiX
w6UAmQHy1fPeMOmwkYiCzV/bOL0sumBv
=l0LS
-END PGP SIGNATURE-

Re: intend to roll 2.3 alpha on Wednesday

[William A. Rowe Jr.]

Paul Querna wrote:
> On Wed, Nov 11, 2009 at 11:56 AM, William A. Rowe Jr.
>  wrote:
>> Graham Leggett wrote:
>>> Paul Querna wrote:
>>>
 I intend to roll a 2.3 alpha release on Wednesday November 11th.
>> +1
>>
 I will bundle APR from the 1.4.x branch. (APR people should make a
 release, but this shouldn't be a blocker for our own alpha releases).
>> Major problem; don't do this.  You are putting 1.4.x code into a release
>> which then ends up causing APR 1.4.0 to break its binary ABI rules.  That
>> is just not kosher.  Some README or release notes observing that the best
>> results can be obtained with a checkout and build of the as-yet-unreleased
>> apr 1.4.x trunk is sufficient.
>>
>> If you want to 'test the bundling' - use a released apr please?
> 
> No released APR works.

It works, but isn't code-complete or bug free; what else is new?

> Under our own versioning guidelines, we can and will break
> compatibilty inside 2.3.x, so I don't see the issue created by using a
> bundled APR.
> 
 I am almost 90% sure the release might fail due to various issues, but
 we need to start cleaning those issues out.
>> :)
>>
>>> Is there a need to bundle APR at all?
>> Agreed +1 if APR is not bundled (this is alpha, after all).
>>
> 
> If APR had a 1.4.0 released, it would be viable, but it doesn't.

Which is altogether irrelevant.

  http://apr.apache.org/versioning.html

is the contract.  By shipping (installing to /usr/lib/ or /usr/local/lib/, etc)
you have started the clock.


You also ask the HTTPD project to release "apr 1.4.0-dev", something which the
APR project hasn't indicated they are ready for.

There is nothing technically impossible about that, and you and the +1 vote
crowd attest that you've reviewed the additions for soundness and all other
incoming code concerns.  And I don't doubt this has happened, knowing the
overlap between the lists.

But do understand this is a release of APR, as the ASF and applicable law all
differentiate that from 'work product' (e.g. svn contents).


I just suggest that tagging 1.4.0 at the same time is very little trouble if
that's what you 'require', and let the results of that bundle alpha swim or
fall based on the results of a 1.4.0 release vote at apr.

Re: [VOTE] release 2.3.3 as alpha

[William A. Rowe Jr.]

Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.3-alpha are available at:
> 
> 
> Your votes please;
> 
>  +/- 1
>  [  ]  Release httpd-2.3.3 as Alpha

-1 for bundled package httpd-2.3.3-alpha-deps - in fact this isn't up to
date w.r.t. pcre 8.

Otherwise, thanks Paul!  My vote and observations about httpd-2.3.3-alpha
base package will follow, but didn't have time to get pcre 8 together, as
it is missing win32 magic as-shipped.  I also plan to assemble 2.3.3 based
on subordinate binary dependencies as-shipped by the mingw crew, just for
a sanity check.

Suggestion; should the release notes/announcement be 'dynamic' on the wiki,
where we can collect realtime observations as users check this out and they
can preview each other's observations?

Re: svn commit: r835046 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

[William A. Rowe Jr.]

rpl...@apache.org wrote:
> Author: rpluem
> Date: Wed Nov 11 20:27:10 2009
> New Revision: 835046
> 
> URL: http://svn.apache.org/viewvc?rev=835046&view=rev
> Log:
> * Use correct #ifndef's to compile again on openssl 0.9.8 and fix compiler
>   warnings.

>  ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
> -#if SSL_LIBRARY_VERSION >= 0x00908000
> +#ifndef OPENSSL_NO_EC

Silly question; this breaks all 0.9.7 builds, right?  Is that deliberate?

Re: svn commit: r835046 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

[Ruediger Pluem]

On 11/11/2009 09:38 PM, William A. Rowe Jr. wrote:
> rpl...@apache.org wrote:
>> Author: rpluem
>> Date: Wed Nov 11 20:27:10 2009
>> New Revision: 835046
>>
>> URL: http://svn.apache.org/viewvc?rev=835046&view=rev
>> Log:
>> * Use correct #ifndef's to compile again on openssl 0.9.8 and fix compiler
>>   warnings.
> 
>>  ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
>> -#if SSL_LIBRARY_VERSION >= 0x00908000
>> +#ifndef OPENSSL_NO_EC
> 
> Silly question; this breaks all 0.9.7 builds, right?  Is that deliberate?

It shouldn't. Does it (no 0.9.7 at hand right now)?

Regards

Rüdiger

Re: svn commit: r835046 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

[Ruediger Pluem]

On 11/11/2009 09:45 PM, Ruediger Pluem wrote:
> 
> On 11/11/2009 09:38 PM, William A. Rowe Jr. wrote:
>> rpl...@apache.org wrote:
>>> Author: rpluem
>>> Date: Wed Nov 11 20:27:10 2009
>>> New Revision: 835046
>>>
>>> URL: http://svn.apache.org/viewvc?rev=835046&view=rev
>>> Log:
>>> * Use correct #ifndef's to compile again on openssl 0.9.8 and fix compiler
>>>   warnings.
>>>  ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
>>> -#if SSL_LIBRARY_VERSION >= 0x00908000
>>> +#ifndef OPENSSL_NO_EC
>> Silly question; this breaks all 0.9.7 builds, right?  Is that deliberate?
> 
> It shouldn't. Does it (no 0.9.7 at hand right now)?

No it doesn't:

Modified: httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h?rev=834378&r1=834377&r2=834378&view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h Tue Nov 10 07:55:13 2009
@@ -48,6 +48,11 @@
 #include 
 #endif

+/* ECC support came along in OpenSSL 1.0.0 */
+#if (OPENSSL_VERSION_NUMBER < 0x1000)
+#define OPENSSL_NO_EC
+#endif
+
 /** Avoid tripping over an engine build installed globally and detected
  * when the user points at an explicit non-engine flavor of OpenSSL
  */

Regards

Rüdiger

Re: intend to roll 2.3 alpha on Wednesday

[Paul Querna]

On Wed, Nov 11, 2009 at 12:14 PM, William A. Rowe Jr.
 wrote:
> Paul Querna wrote:
>> On Wed, Nov 11, 2009 at 11:56 AM, William A. Rowe Jr.
>>  wrote:
>>> Graham Leggett wrote:
 Paul Querna wrote:

> I intend to roll a 2.3 alpha release on Wednesday November 11th.
>>> +1
>>>
> I will bundle APR from the 1.4.x branch. (APR people should make a
> release, but this shouldn't be a blocker for our own alpha releases).
>>> Major problem; don't do this.  You are putting 1.4.x code into a release
>>> which then ends up causing APR 1.4.0 to break its binary ABI rules.  That
>>> is just not kosher.  Some README or release notes observing that the best
>>> results can be obtained with a checkout and build of the as-yet-unreleased
>>> apr 1.4.x trunk is sufficient.
>>>
>>> If you want to 'test the bundling' - use a released apr please?
>>
>> No released APR works.
>
> It works, but isn't code-complete or bug free; what else is new?
>

APR 1.3.x does not contain APIs used by httpd 2.3.3.  Those APIs are
added in APR 1.4.x.

That is the root of the problem.  'does not work' == does not compile.

Re: [VOTE] release 2.3.3 as alpha

[Ruediger Pluem]

On 11/11/2009 08:54 PM, Paul Querna wrote:
> Test tarballs for Apache httpd 2.3.3-alpha are available at:
> 
> 
> Your votes please;
> 
>  +/- 1
>  [  ]  Release httpd-2.3.3 as Alpha
> 
> Vote closes at 18:00 UTC on Sunday November 15 2009.

-1: mod_ssl does not compile with OpenSSL before 1.0
(fixed in r835046).

Regards

Rüdiger

Re: intend to roll 2.3 alpha on Wednesday

[Jeff Trawick]

On Wed, Nov 11, 2009 at 3:14 PM, William A. Rowe Jr.
 wrote:
> Paul Querna wrote:
>> On Wed, Nov 11, 2009 at 11:56 AM, William A. Rowe Jr.
>>  wrote:
>>> Graham Leggett wrote:
 Paul Querna wrote:

> I intend to roll a 2.3 alpha release on Wednesday November 11th.
>>> +1
>>>
> I will bundle APR from the 1.4.x branch. (APR people should make a
> release, but this shouldn't be a blocker for our own alpha releases).
>>> Major problem; don't do this.  You are putting 1.4.x code into a release
>>> which then ends up causing APR 1.4.0 to break its binary ABI rules.  That
>>> is just not kosher.  Some README or release notes observing that the best
>>> results can be obtained with a checkout and build of the as-yet-unreleased
>>> apr 1.4.x trunk is sufficient.
>>>
>>> If you want to 'test the bundling' - use a released apr please?
>>
>> No released APR works.
>
> It works, but isn't code-complete or bug free; what else is new?
>
>> Under our own versioning guidelines, we can and will break
>> compatibilty inside 2.3.x, so I don't see the issue created by using a
>> bundled APR.
>>
> I am almost 90% sure the release might fail due to various issues, but
> we need to start cleaning those issues out.
>>> :)
>>>
 Is there a need to bundle APR at all?
>>> Agreed +1 if APR is not bundled (this is alpha, after all).
>>>
>>
>> If APR had a 1.4.0 released, it would be viable, but it doesn't.
>
> Which is altogether irrelevant.
>
>  http://apr.apache.org/versioning.html
>
> is the contract.  By shipping (installing to /usr/lib/ or /usr/local/lib/, 
> etc)
> you have started the clock.

I'm missing something...

As long as this snapshot of APR says 1.4.0-dev, the versioning
requirements are moot.  Even the APR project will need to release
something non-GA that hopefully looks a lot like the eventual first
1.4 GA release, but without version constraints until feedback from
outside of the project is received.


> 
> You also ask the HTTPD project to release "apr 1.4.0-dev", something which the
> APR project hasn't indicated they are ready for.

APR will never release -dev, right?  And as far as svn checkouts or
third-party snapshots, there's no promise that one APR 1.4.0-dev looks
like another 1.4.0-dev.

>
> There is nothing technically impossible about that, and you and the +1 vote
> crowd attest that you've reviewed the additions for soundness and all other
> incoming code concerns.  And I don't doubt this has happened, knowing the
> overlap between the lists.
>
> But do understand this is a release of APR, as the ASF and applicable law all
> differentiate that from 'work product' (e.g. svn contents).
> 
>
> I just suggest that tagging 1.4.0 at the same time is very little trouble if
> that's what you 'require', and let the results of that bundle alpha swim or
> fall based on the results of a 1.4.0 release vote at apr.
>
>
>
>

Re: svn commit: r835046 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

[William A. Rowe Jr.]

Ruediger Pluem wrote:
> 
>>> Silly question; this breaks all 0.9.7 builds, right?  Is that deliberate?
>> It shouldn't. Does it (no 0.9.7 at hand right now)?
> No it doesn't:
> 
> --- httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h Tue Nov 10 07:55:13 
> 2009
> 
> +/* ECC support came along in OpenSSL 1.0.0 */
> +#if (OPENSSL_VERSION_NUMBER < 0x1000)
> +#define OPENSSL_NO_EC
> +#endif
> +

Can we PLEASE use the same hack for OCSP to avoid taking five different 
solutions
to the very same problem set?  That would be kindness :)

:)

dav_new_error_*() and errno, revisit before 2.4 GA

[Jeff Trawick]

At present, whatever was in errno at the time the dav_error {} was
created is treated as an apr_status_t by ap_log_rerror().

http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e

dav_error {} should have an apr_status_t field instead of an errno
field; functions which create a dav_error should have an apr_status_t
parameter.

If there's no direct apr_status_t representation of the error, the
caller will have to decide what to do (no magic portable solution
AFAIK, but no worse than today).

Concerns?

Re: [VOTE] release 2.3.3 as alpha

[Paul Querna]

On Wed, Nov 11, 2009 at 12:36 PM, William A. Rowe Jr.
 wrote:
> Paul Querna wrote:
>> Test tarballs for Apache httpd 2.3.3-alpha are available at:
>>     
>>
>> Your votes please;
>>
>>  +/- 1
>>  [  ]  Release httpd-2.3.3 as Alpha
>
> -1 for bundled package httpd-2.3.3-alpha-deps - in fact this isn't up to
> date w.r.t. pcre 8.

the -deps package does not contain PCRE at all.  The only software
contained inside the -deps package is APR and APR-Util, so I am not
quite sure what your comment about PCRE 8 is referencing.

Thanks,

Paul

Re: [VOTE] release 2.3.3 as alpha

[William A. Rowe Jr.]

Paul Querna wrote:
> 
> the -deps package does not contain PCRE at all.  The only software
> contained inside the -deps package is APR and APR-Util, so I am not
> quite sure what your comment about PCRE 8 is referencing.

Didn't realize that was dropped...

...if we presume sense and sensibility of the user to install pcre
(and apr project eventually assumes the same w.r.t. expat) and we don't
see a benefit to shipping the [very small] lua sources, then it's really
nothing to assert that apr should never be bundled again.

Otherwise, if we have a -deps package, the prereq packages such as pcre
must be bundled for consistency.

Getting out of the dep-distro business seems like a sensible move.

Re: dav_new_error_*() and errno, revisit before 2.4 GA

[Greg Stein]

On Wed, Nov 11, 2009 at 17:11, Jeff Trawick  wrote:
> At present, whatever was in errno at the time the dav_error {} was
> created is treated as an apr_status_t by ap_log_rerror().
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
>
> dav_error {} should have an apr_status_t field instead of an errno
> field; functions which create a dav_error should have an apr_status_t
> parameter.
>
> If there's no direct apr_status_t representation of the error, the
> caller will have to decide what to do (no magic portable solution
> AFAIK, but no worse than today).
>
> Concerns?

dav_error was designed during the 1.3 series. APR wasn't even being
discussed. So yeah... there is definitely a disconnect from "then" to
"now".

I'd be quite supportive of changing that, though (strictly speaking)
that is probably an API change.

Cheers,
-g

Re: [VOTE] release 2.3.3 as alpha

[Paul Querna]

On Wed, Nov 11, 2009 at 11:54 AM, Paul Querna  wrote:
> Test tarballs for Apache httpd 2.3.3-alpha are available at:
>    
>
> Your votes please;
>
>  +/- 1
>  [  ]  Release httpd-2.3.3 as Alpha
>
> Vote closes at 18:00 UTC on Sunday November 15 2009.
>

www.apache.org  (and TLPs) is now running 2.3.3, on the event MPM:


Problems:
 - the generated configure scripts failed to run with /bin/sh on
Solaris 10. I had to edit all of them to use /bin/bash.  ENOCLUE why
this is. Maybe a bug in newer autoconf I used to generate configure on
my mac.
 - It had problems linking libpcre on aurora.apache.org -- I had to
add a  -R/opt/sfw/lib to the LDFLAGS.  I already have to hack LDFLAGS
on these solaris machines to get BerkeleyDB to link correctly, so not
really a regression I guess.

Otherwise, it seems to mostly be working so far, with mod_fcgid running too.

Thanks,

Paul

Re: dav_new_error_*() and errno, revisit before 2.4 GA

[Jeff Trawick]

On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein  wrote:
> On Wed, Nov 11, 2009 at 17:11, Jeff Trawick  wrote:
>> At present, whatever was in errno at the time the dav_error {} was
>> created is treated as an apr_status_t by ap_log_rerror().
>>
>> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
>>
>> dav_error {} should have an apr_status_t field instead of an errno
>> field; functions which create a dav_error should have an apr_status_t
>> parameter.
>>
>> If there's no direct apr_status_t representation of the error, the
>> caller will have to decide what to do (no magic portable solution
>> AFAIK, but no worse than today).
>>
>> Concerns?
>
> dav_error was designed during the 1.3 series. APR wasn't even being
> discussed. So yeah... there is definitely a disconnect from "then" to
> "now".
>
> I'd be quite supportive of changing that, though (strictly speaking)
> that is probably an API change.

well, yes it is an API change ;)  I think the issue is whether or not
you in the DAV community want to push it on your third-party
colleagues.

A third-party mod could define something like this for compatibility:

#if AP_MODULE_MAGIC_AT_LEAST(xxx,y)
#define foo_dav_new_error(p, stat, errid, rv, desc) \
dav_new_error(p, stat, errid, rv, desc)
#else
#define foo_dav_new_error(p, stat, errid, rv, desc) \
  (errno = (rv),   \
   dav_new_error(p, stat, errid, desc))
#endif

and go ahead and change its code to pass in an apr_status_t.

If it is too ugly to force this on third-party modules, we'll need to
add new APIs and use those ourselves, as it is too ugly for us to keep
mismanaging the error codes.

Re: [VOTE] release 2.3.3 as alpha

[Paul Querna]

On Wed, Nov 11, 2009 at 4:42 PM, Paul Querna  wrote:
> On Wed, Nov 11, 2009 at 11:54 AM, Paul Querna  wrote:
>> Test tarballs for Apache httpd 2.3.3-alpha are available at:
>>    
>>
>> Your votes please;
>>
>>  +/- 1
>>  [  ]  Release httpd-2.3.3 as Alpha
>>
>> Vote closes at 18:00 UTC on Sunday November 15 2009.
>>
>
> www.apache.org  (and TLPs) is now running 2.3.3, on the event MPM:
> 
>
> Problems:
>  - the generated configure scripts failed to run with /bin/sh on
> Solaris 10. I had to edit all of them to use /bin/bash.  ENOCLUE why
> this is. Maybe a bug in newer autoconf I used to generate configure on
> my mac.
>  - It had problems linking libpcre on aurora.apache.org -- I had to
> add a  -R/opt/sfw/lib to the LDFLAGS.  I already have to hack LDFLAGS
> on these solaris machines to get BerkeleyDB to link correctly, so not
> really a regression I guess.

It also seems there is a bug in APR-Util's build for the DSO loading
of DBM drivers.

When using jlibtool, $prefix//lib/apr-util-1/apr_dbm_db.so is created.
 When loading the DSO, APR-Util looks for
$prefix//lib/apr-util-1/apr_dbm_db-1.so (trailing MAJOR version added
to the DSO name).

To work around it, I just made a symlink:
sudo ln -s 
/usr/local/apache2-install/www.apache.org/2.3.3/lib/apr-util-1/apr_dbm_db.so

/usr/local/apache2-install/www.apache.org/2.3.3/lib/apr-util-1/apr_dbm_db-1.so

Obsolete modules in 2.3

[Rich Bowen]

Don't you think that maybe it's time to drop mod_imagemap and  
mod_cern_meta?


"there is already a large number of CERN users who can exploit this  
module."


Seriously?

--
Rich Bowen
rbo...@rcbowen.com

Re: Obsolete modules in 2.3

[Nick Kew]

On 12 Nov 2009, at 01:56, Rich Bowen wrote:

> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
> 
> "there is already a large number of CERN users who can exploit this module."
> 
> Seriously?

mod_imagemap is a perfectly good application module, albeit a minority
interest one.  I don't think we should drop it unless we finally get around
to implementing a CPAN-style module repository we can offer it from.

But why not put the question to users@ for a more diverse audience?

-- 
Nick Kew

2.3.3 on Mac OS X

[Rich Bowen]

Built 2.3.3 on Mac OS X 10.5.8 with:

"./configure" \
"--enable-modules=most" \
"--enable-mods-shared=all" \
"--with-mpm=event" \
"--prefix=/usr/local/apache" \


and got this on startup:

[Wed Nov 11 20:56:15 2009] [crit] (70023)This function has not been  
implemented on this platform: Couldn't create a Thread Safe Pollset.  
Is it supported on your platform?Also check system or user limits!

Pre-configuration failed

Built and ran fine with worker mpm.

--
Rich Bowen
rbo...@rcbowen.com

Re: 2.3.3 on Mac OS X

[Jeff Trawick]

On Wed, Nov 11, 2009 at 9:03 PM, Rich Bowen  wrote:
> Built 2.3.3 on Mac OS X 10.5.8 with:
>
> "./configure" \
> "--enable-modules=most" \
> "--enable-mods-shared=all" \
> "--with-mpm=event" \
> "--prefix=/usr/local/apache" \
>
>
> and got this on startup:
>
> [Wed Nov 11 20:56:15 2009] [crit] (70023)This function has not been
> implemented on this platform: Couldn't create a Thread Safe Pollset. Is it

this part of server/mpm/config.m4 needs some help:

dnl See if APR supports APR_POLLSET_THREADSAFE.
dnl XXX This hack tests for the underlying functions used by APR when it
dnl XXX supports APR_POLLSET_THREADSAFE.
dnl FIXME with a run-time check for
dnl apr_pollset_create(,,APR_POLLSET_THREADSAFE) == APR_SUCCESS
AC_CHECK_FUNCS(kqueue port_create epoll_create)
if test "$ac_cv_func_kqueue$ac_cv_func_port_create$ac_cv_func_epoll_create"
!= "nonono"; then
have_threadsafe_pollset=yes
else
have_threadsafe_pollset=no
fi

(APR actually skips kqueue on Leopard because of kernel issues.)

Re: dav_new_error_*() and errno, revisit before 2.4 GA

[Greg Stein]

On Wed, Nov 11, 2009 at 20:09, Jeff Trawick  wrote:
> On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein  wrote:
>> On Wed, Nov 11, 2009 at 17:11, Jeff Trawick  wrote:
>>> At present, whatever was in errno at the time the dav_error {} was
>>> created is treated as an apr_status_t by ap_log_rerror().
>>>
>>> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
>>>
>>> dav_error {} should have an apr_status_t field instead of an errno
>>> field; functions which create a dav_error should have an apr_status_t
>>> parameter.
>>>
>>> If there's no direct apr_status_t representation of the error, the
>>> caller will have to decide what to do (no magic portable solution
>>> AFAIK, but no worse than today).
>>>
>>> Concerns?
>>
>> dav_error was designed during the 1.3 series. APR wasn't even being
>> discussed. So yeah... there is definitely a disconnect from "then" to
>> "now".
>>
>> I'd be quite supportive of changing that, though (strictly speaking)
>> that is probably an API change.
>
> well, yes it is an API change ;)  I think the issue is whether or not
> you in the DAV community want to push it on your third-party
> colleagues.
>
> A third-party mod could define something like this for compatibility:
>
> #if AP_MODULE_MAGIC_AT_LEAST(xxx,y)
> #define foo_dav_new_error(p, stat, errid, rv, desc) \
>    dav_new_error(p, stat, errid, rv, desc)
> #else
> #define foo_dav_new_error(p, stat, errid, rv, desc) \
>  (errno = (rv),                                   \
>   dav_new_error(p, stat, errid, desc))
> #endif
>
> and go ahead and change its code to pass in an apr_status_t.
>
> If it is too ugly to force this on third-party modules, we'll need to
> add new APIs and use those ourselves, as it is too ugly for us to keep
> mismanaging the error codes.

I have no opinion in this space. I'm very much out of touch nowadays
with the mod_dav users/community. The one particular user of mod_dav
that I'm concerned with is mod_dav_svn, and *that* is about to become
an Apache project :-)

svn can certainly use that macro. "You" get to measure the disruption
to other API users of Apache.

In fact, we floated the idea of whether mod_dav_svn can/should be
transferred over to httpd, rather than maintained as part of svn.
Total random comment, but a couple people went "hmm" It would be
kinda neat for any Apache server to have built-in support for svn :-)
(and would solve a bunch of versioning combinatorics for svn...)

Cheers,
-g

Re: Obsolete modules in 2.3

[Greg Stein]

On Wed, Nov 11, 2009 at 20:56, Rich Bowen  wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
> "there is already a large number of CERN users who can exploit this module."
> Seriously?

I say "hell yes".

And my response to a user would be "you want that? fine. it is in
apache 2.2. kthxbai."

Cheers,
-g

Re: Httpd 3.0 or something else

[Greg Stein]

On Wed, Nov 11, 2009 at 15:00, Arturo 'Buanzo' Busleiman
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Greg Stein wrote:
>> Right. But they don't have the depth/breadth of modules like we do.
>
> ... yet. Keep going, but if there are great things like lighttpd and nginx 
> (and even more) http
> daemons out there, then that means more than one thing is wrong with current 
> Apache.

Oh, definitely. HTTP serving is commodity functionality now. Thus, it
is very easy to serve niches with a specialized HTTP server.

Apache remains the broad solution, but for narrow requirements, people
will select something that is easier to handle for their particular
situation.

I wouldn't say "wrong", but more along the lines of "not as well-suited"

Cheers,
-g

Re: Obsolete modules in 2.3

[William A. Rowe Jr.]

Rich Bowen wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
> 
> "there is already a large number of CERN users who can exploit this module."
> 
> Seriously?

LOL

FWIW I know of one customer who absolutely continues to use mod_imagemap and
have no indication they plan to drop it.

modules/historical/ might be a good waypoint to eliminating these.  Enabling
them should emit a warning they are no longer interesting and likely to be
dropped from future releases.  OTOH perhaps we should keep cern_meta, 
considering
the underlying argument from fans of over-aggressive content-type sniffing 
always
cite broken httpd configs as the reason for their sillyness.

Re: Obsolete modules in 2.3

[Greg Stein]

On Wed, Nov 11, 2009 at 23:21, William A. Rowe Jr.  wrote:
> Rich Bowen wrote:
>> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
>>
>> "there is already a large number of CERN users who can exploit this module."
>>
>> Seriously?
>
> LOL
>
> FWIW I know of one customer who absolutely continues to use mod_imagemap and
> have no indication they plan to drop it.
>
> modules/historical/ might be a good waypoint to eliminating these.  Enabling
> them should emit a warning they are no longer interesting and likely to be
> dropped from future releases.  OTOH perhaps we should keep cern_meta, 
> considering
> the underlying argument from fans of over-aggressive content-type sniffing 
> always
> cite broken httpd configs as the reason for their sillyness.
>

Bah. If they want them, then they should not upgrade their server.
Simple as that.

Cheers,
-g

Re: Obsolete modules in 2.3

[William A. Rowe Jr.]

Greg Stein wrote:
>> FWIW I know of one customer who absolutely continues to use mod_imagemap and
>> have no indication they plan to drop it.
>>
>> modules/historical/ might be a good waypoint to eliminating these.  Enabling
>> them should emit a warning they are no longer interesting and likely to be
>> dropped from future releases.  OTOH perhaps we should keep cern_meta, 
>> considering
>> the underlying argument from fans of over-aggressive content-type sniffing 
>> always
>> cite broken httpd configs as the reason for their sillyness.
> 
> Bah. If they want them, then they should not upgrade their server.
> Simple as that.

w.r.t. imagemap, fine, they can build this out-of-tree.  w.r.t. cern_meta, I'm 
just
not seeing the logic behind removing it, any more or less than mime_magic.

Re: [VOTE] release 2.3.3 as alpha

[Gregg L. Smith]

Hello,

I did not get far

inet_pton.c
multicast.c
Generating Code...
Compiling...
socket_util.c
E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21) 
: error C2373: 'apr_socket_atreadeof' : redefinition; different type 
modifiers
./include\apr_network_io.h(362) : see declaration of 
'apr_socket_atreadeof'

sendrecv.c
sockaddr.c


Paul Querna wrote:

Test tarballs for Apache httpd 2.3.3-alpha are available at:


Your votes please;

 +/- 1
 [  ]  Release httpd-2.3.3 as Alpha

Vote closes at 18:00 UTC on Sunday November 15 2009.

Thanks,

Paul





No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.425 / Virus Database: 270.14.60/2495 - Release Date: 11/10/09 19:56:00

Re: [VOTE] release 2.3.3 as alpha

[William A. Rowe Jr.]

Gregg L. Smith wrote:
> Hello,
> 
> I did not get far
> 
> Generating Code...
> socket_util.c
> E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21)
> : error C2373: 'apr_socket_atreadeof' : redefinition; different type
> modifiers
> ./include\apr_network_io.h(362) : see declaration of
> 'apr_socket_atreadeof'

We are missing a ton of information here; what VisualStudio and VC version
are you running, what SDK's have you updated?  That will be a good start.

Re: [VOTE] release 2.3.3 as alpha

[William A. Rowe Jr.]

> E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21)
> : error C2373: 'apr_socket_atreadeof' : redefinition; different type
> modifiers
> ./include\apr_network_io.h(362) : see declaration of
> 'apr_socket_atreadeof'

This is probably nothing but missing/mismatched APR_DECLARE macros.
One of the difficulties of shipping uninspected code :)

Re: [VOTE] release 2.3.3 as alpha

[Gregg L. Smith]

Sorry bout that,

I always try first with VS6 SP6 SDK 2003R2

I'm more curious why it is trying to build the 'unix' file in the first 
place since there is a Win32 alternative


Gregg

William A. Rowe Jr. wrote:

Gregg L. Smith wrote:

Hello,

I did not get far

Generating Code...
socket_util.c
E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21)
: error C2373: 'apr_socket_atreadeof' : redefinition; different type
modifiers
./include\apr_network_io.h(362) : see declaration of
'apr_socket_atreadeof'


We are missing a ton of information here; what VisualStudio and VC version
are you running, what SDK's have you updated?  That will be a good start.





No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.425 / Virus Database: 270.14.61/2497 - Release Date: 11/11/09 19:41:00

Re: [VOTE] release 2.3.3 as alpha

[Graham Dumpleton]

2009/11/12 Paul Querna :
> Test tarballs for Apache httpd 2.3.3-alpha are available at:
>    
>
> Your votes please;
>
>  +/- 1
>  [  ]  Release httpd-2.3.3 as Alpha
>
> Vote closes at 18:00 UTC on Sunday November 15 2009.
>
> Thanks,
>
> Paul
>

What APR/APR-UTIL/PCRE versions are supposed to be used with this?

Failing to build on MacOS X 10.5.8.

Configure line:

./configure --prefix=/usr/local/apache-2.3
--with-apr=/usr/local/apr-1.4/bin/apr-1-config
--with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config
--with-pcre=/usr/local/pcre-8.00/bin/pcre-config

Build error:

/usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2
  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp-I.
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/include
-I/usr/local/apr-1.4/include/apr-1
-I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/generators
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/mappers
-prefer-non-pic -static -c htpasswd.c && touch htpasswd.lo
/usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2
   -o htpasswd  htpasswd.lo
/usr/local/apr-util-1.4/lib/libaprutil-1.la @LDADD_dbm_db@
@LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_db@: No such file or directory
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_gdbm@: No such file or directory
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_ndbm@: No such file or directory

The config.log shows:

AP_LIBS='$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD)
$(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD)
$(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD)
$(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD)
$(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD)
$(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEOUT_LDADD) $(MOD_REQUEST_LDADD)
$(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD)
$(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION_LDADD)
$(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD)
$(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD)
$(MOD_CGID_LDADD) $(MOD_NEGOTIATION_LDADD) $(MOD_DIR_LDADD)
$(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD)
/usr/local/apr-util-1.4/lib/libaprutil-1.la  @LDADD_dbm_db@
@LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread'

but no other mention of those non substituted values.

The config.status just reflects same thing:

S["AP_LIBS"]="$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD)
$(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD)
$(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD)"\
" $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD)
$(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD)
$(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEO"\
"UT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD)
$(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD)
$(MOD_SETENVIF_LDADD) $(MOD_VERSION"\
"_LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD)
$(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD)
$(MOD_CGID_LDADD) $(MOD_"\
"NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD)
$(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD)
/usr/local/apr-util-1.4/lib/libaprutil-1.la  @LDAD"\
"D_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread"

Had noticed this problem in subversion trunk couple of days before you
rolled this tarball but didn't have a chance to post anything.

If remove those values from build/config_vars.mk and continue build
then stops with:

/usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2
  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp-I.
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/include
-I/usr/local/apr-1.4/include/apr-1
-I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache
-I/Users/grahamd/Packages/http

Re: [VOTE] release 2.3.3 as alpha

[Gregg L. Smith]

Hello again,

While were at it.
I dropped in APR/Util 1.3.9 and had a go at it.
I'll guess this error is because of it but in case it isn't;
Configuration: mod_ldap - Win32 
Release

Compiling resources...
Compiling...
util_ldap.c
E:\build\httpd-2.3.3-alpha\modules\ldap\util_ldap.c(2667) : error C2065: 
'AP_LDAP_OPT_DEBUG' : undeclared identifier

util_ldap_cache.c
util_ldap_cache_mgr.c
Generating Code...
Error executing cl.exe.

VS6 SP6 SDK 2003 R2 Win32-Release

Gregg


Paul Querna wrote:

Test tarballs for Apache httpd 2.3.3-alpha are available at:


Your votes please;

 +/- 1
 [  ]  Release httpd-2.3.3 as Alpha

Vote closes at 18:00 UTC on Sunday November 15 2009.

Thanks,

Paul





No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.425 / Virus Database: 270.14.60/2495 - Release Date: 11/10/09 19:56:00

Re: [VOTE] release 2.3.3 as alpha

[William A. Rowe Jr.]

Gregg L. Smith wrote:
> Hello again,
> 
> While were at it.
> I dropped in APR/Util 1.3.9 and had a go at it.

> Compiling...
> util_ldap.c
> E:\build\httpd-2.3.3-alpha\modules\ldap\util_ldap.c(2667) : error C2065:
> 'AP_LDAP_OPT_DEBUG' : undeclared identifier

This looks like a purely httpd error; AP_ is the httpd namespace, nothing at
all to do with apr.

Re: [VOTE] release 2.3.3 as alpha

[Gregg L. Smith]

Hi Bill,

I know this, even better now ;) ... will remember to pay more attention.

Since I have your eyes yet again, makefile.win wants to copy pcre.pdb 
but my out-of-tree pcre does not include that file, the .dll is there, 
not the pdb. Can this made to make noise only and not stop the copy 
process at this point like it does with openssl. I always get these 
warnings with openssl.exe, libeay.dll and ssleay.dll in 2.2 but it never 
stops the process with a fatal.


For the time I let it stop (to copy the dll) and then commented out the 
line (585) and let it run away from there. Since these are by default 
not included in the out-of-tree builds can we just copy the dlls and 
drop the pdbs from the copy command?


Thanks
Gregg


William A. Rowe Jr. wrote:

Gregg L. Smith wrote:

Hello again,

While were at it.
I dropped in APR/Util 1.3.9 and had a go at it.



Compiling...
util_ldap.c
E:\build\httpd-2.3.3-alpha\modules\ldap\util_ldap.c(2667) : error C2065:
'AP_LDAP_OPT_DEBUG' : undeclared identifier


This looks like a purely httpd error; AP_ is the httpd namespace, nothing at
all to do with apr.