Re: Fuzzing integration with oss-fuzz

[Paul Querna]

Years ago I started hacking on an "mpm fuzz":
https://github.com/pquerna/httpd/compare/trunk...pquerna:mpm_fuzz

The idea was to make a "fake" MPM, which could feed data from AFL directly
into the network filter stack, in a super efficient way.

I don't know if it is really a great idea, since TLS and h2 are maybe hard
to get right in the stack, but its a different approach that could lead to
high coverage of critical remote network paths.

Not sure it's the right way to go about it, but thought I'd mention it as a
potential approach to deep fuzzing.


On Fri, Jul 16, 2021 at 4:02 AM david korczynski 
wrote:

> Hi all,
>
> I have been working on getting fuzzing into Apache httpd and it would be
> great to have it set up with OSS-Fuzz. OSS-Fuzz is a free service run by
> Google that will continuously run fuzzers and the service is
> administrered on github (https://github.com/google/oss-fuzz).
> Apache-commons is already integrated into OSS-Fuzz (see here:
> https://github.com/google/oss-fuzz/pull/5633)
>
> I have done initial work on fuzzing httpd which can be found in this PR:
> https://github.com/google/oss-fuzz/pull/6044
>
> I am happy to continue working more on improving the fuzzing so we can
> get a high code coverage of httpd, but I would prefer to do this only if
> the developers of httpd are happy to receive bug reports from the
> fuzzers. In order to integrate with OSS-Fuzz the only thing needed is a
> set of email addresses that will receive the bug reports, and these
> emails need to be affiliated with a Google account (for login purposes).
>
> Let me know if you are happy to integrate httpd into OSS-Fuzz.
>
> Kind regards,
> David
>
> ADA Logics Ltd is registered in England. No: 11624074.
> Registered office: 266 Banbury Road, Post Box 292,
> OX2 7DL, Oxford, Oxfordshire , United Kingdom
>

Re: [VOTE] Allow for defect fix releases at httpd

[Paul Querna]

FTR I support moving to this versioning model.

I tend to think the best way to accomplish it, is to "just start doing
it".   Tag 2.6.0.  Then tag 2.7.0 when there are new features, etc.
Of course, our versioning docs don't support this model, but the docs
are a reflection of reality 15 years ago more so than current
attitudes.  Make the docs reflect reality as it changes rather than
upfront votes unless absolutely necessary.

Is a vote like the above required to just start making minor releases
that contain new features, and making patch releases only contain bug
fixes?



On Mon, Apr 30, 2018 at 9:26 AM, William A Rowe Jr  wrote:
> On Thu, Apr 26, 2018 at 1:51 PM, William A Rowe Jr 
> wrote:
>>
>>
>>   [  ] The Apache HTTP Server project facilitates the release
>>of bug fixes to the current stable httpd release, correcting
>>defects to previously released code, excluding all new
>>features and enhancements. This is facilitated without
>>inhibiting development of new features and enhancements,
>>including the evolution release of candidates to the public
>>of new features and enhancements under consideration.
>
>
> As there are not three PMC members interested in delivering
> bug fix releases to our users, this question fails. I'm withdrawing
> any suggestion to find mechanisms to accomplish this goal.
>
>

Re: A proposal...

[Paul Querna]

On Mon, Apr 23, 2018 at 11:17 AM, Christophe Jaillet
 wrote:
> Le 23/04/2018 à 16:00, Jim Jagielski a écrit :
>>
>> It seems that, IMO, if there was not so much concern about "regressions"
>> in releases, this whole revisit-versioning debate would not have come up.
>> This implies, to me at least, that the root cause (as I've said before)
>> appears to be one related to QA and testing more than anything. Unless we
>> address this, then nothing else really matters.
>>
>> We have a test framework. The questions are:
>>
>>   1. Are we using it?
>>   2. Are we using it sufficiently well?
>>   3. If not, what can we do to improve that?
>>   4. Can we supplement/replace it w/ other frameworks?
>>
>> It does seem to me that each time we patch something, there should be a
>> test added or extended which covers that bug. We have gotten lax in that.
>> Same for features. And the more substantial the change (ie, the more core
>> code it touches, or the more it refactors something), the more we should
>> envision what tests can be in place which ensure nothing breaks.
>>
>> In other words: nothing backported unless it also involves some changes to
>> the Perl test framework or some pretty convincing reasons why it's not
>> required.
>>
>
> Hi,
> +1000 on my side for more tests.
>
> But, IMHO, the perl framework is complex to understand for most of us.
>
> Last week I tried to play with it. I tried to update proxy_balancer.t
> because only lbmethod=byrequests is tested.
> The current test itself is really simple. It just checks if the module
> didn't crashed (i.e we receive 200).
> I tried to extend it for the other lbmethod available. This looked as an
> easy task. But figuring the relation between:
>
> and
>BalancerMember http://@SERVERNAME@:@PROXY_HTTP_BAL1_PORT@
> still remains a mystery to me.
>
>
> The ./test framework could be useful as well.
> At least it is written in C, so the entry ticket should be cheaper for most
> of us.
> But every thing can't be done with it, I guess.
> Maybe, we should at least have some unit testing for each ap_ function? The
> behavior of these function should not change as it can be used by 3rd party
> modules.

I agree that having a quick way to make function level tests would be
very helpful.  It's something largely missing from httpd. (APR has
more)

Even in making mod_log_json, testing it via the test framework is
complicated, as its not a module that changes the output of an HTTP
Request, vs I could make a few quick C-based tests that make sure
things are being serialized correctly very easily.

> The more tests, the better, but I believe that most regressions come from
> interaction between all what is possible with httpd.
> A test-suite is only a test-suite. Everything can't be tested.
>
>
> IMHO, as a minimum, all CVE should have their dedicated test which
> explicitly fails with version n, and succeeds with version n+1.
> It would help to make sure than known security issues don't come back.
>
>
>
> Another question with the perl framework.
> Is there a way to send "invalid" data/request with it?
> All, I see is some GET(...). I guess that it sends well formed date.
> Checking the behavior when invalid queries are received would be great.
> Some kind of RFC compliancy check.
>
>
> just my 2c,
> CJ

Re: Start using RCs

[Paul Querna]

On Mon, Apr 23, 2018 at 10:10 AM, Micha Lenk  wrote:
> On 04/23/2018 06:33 PM, William A Rowe Jr wrote:
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk  wrote:
>>>
>>> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:

 We have a history, as well as a published "agreement" on what minor
 version numbering means.
>>>
>>>
>>> Just to make sure I am on the same page, would you mind to make that
>>> explicit? Where is that published?
>>
>>
>> http://httpd.apache.org/dev/release.html
>
>
> The only paragraph on that page that contains the word "minor" is the second
> one in the Introduction section. It isn't very verbose either. Am I missing
> something obvious?
>
> Regards,
> Micha

https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

Contains a much more verbose... non-semver versioning scheme.

new module: mod_log_json

[Paul Querna]

Morning dev@,

I just committed mod_log_json to trunk in r1829898.

Right now, to use it you need something like this:

LogFormat "%^JS" json
CustomLog "logs/access_log.json" json

Currently it has a static format of the JSON, and example message is like this:

{
  "log_id": null,
  "vhost": "127.0.0.1",
  "status": "404",
  "proto": "HTTP\/1.1",
  "method": "GET",
  "uri": "\/x",
  "srcip": "127.0.0.1",
  "bytes_sent": 199,
  "hdrs": {
"user-agent": "curl\/7.54.0"
  }
}


Some changes I'd like to figure out:

- Right now mod_log_json is a format string to mod_log_config -- this
is mostly to be able to leverage mod_log_config's support to write to
many outputs (files, buffered logs, pipes, programs, etc).

- Leveraging the existing mod_log_config format strings.  Exposing the
internal hash of callbacks isn't that hard, I experimented with adding
a hook of that here
,
but a bigger refactoring is needed to expose mod_log_config's parsing
of the format strings, rather than just their key-names.

- mod_log_json is not configurable right now, the format is static.
Obviously, being able to configure what is logged, what headers, etc
is valuable. I played with some options here, but wasn't happy with
it.  Any ideas?

- (small) I'd like to be able to log in RFC-3339 timestamps, in
JSON-world this seems like the most common format by far.  Just need
to do the work to export an apr_time_t that way, I don't think there
is existing code for that?

Cheers,

Paul

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Paul Querna]

I believe having more minor releases and less major backports to patch
releases is a good thing.

I believe we gave the even/odd, 2.1/2.3 "unstable", thing a long run.
About 15 years of it.

Since then the wider open source world has gone to a more canonical
semver.  I think we should generally align with that.


As an outcome, that would mean more major & minor releases, and less
patch releases.  I think that if we break an existing ABI, we need to
bump the major.  I think other projects are successfully doing this,
and it has little effect on how distributions are packaging their
projects.  Distros pick a point in time, whatever the current
major.minor.patch is.


On Fri, Apr 20, 2018 at 5:04 AM, Micha Lenk  wrote:
> Hi all,
>
> On 04/20/2018 01:34 PM, Jim Jagielski wrote:
>>
>> But why does it matter that h2 was added in 2.4.x instead of
>> a 2.6.0?
>
>
> Because it sets a bad precedence (or even continues to do so)?
>
>> Every new feature must bump the minor? Even if
>> there is no corresponding ABI issue?
>
>
> Why not?
>
> In my role as Debian Developer maintaining the Debian packages of other OSS
> projects, and also in my role of maintaining a commercial reverse proxy
> product based on Apache httpd during my day job, I value the ability to
> distinguish between bugfix-only releases and feature addition releases.
>
> This does not mean that a minor bump needs to happen at almost every
> release. But not bumping the minor for years (which seems to be the current
> pattern of the httpd project) is just worse, because it increases the
> incentive to squeeze features like h2 into releases that are meant (or
> perceived) as bugfix-only releases.
>
> Regards,
> Micha

Re: Serf support in trunk

[Paul Querna]

As the author, I'm fine with it being removed.  I don't think updating
it would be particularly hard, but I don't have personal interest in
improving mod_proxy with serf at this time.

On Sun, Nov 19, 2017 at 3:49 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> While testing the 2.5.0 alpha candidate I noticed, that our optional use of
> serf in mod_proxy and mpm_event is pretty outdated (so unmaintained):
>
> - the serf API we use was only present in serf until version 0.3.1 (February
> 2010)
>
> - in May 2010 it was changed inside serf and httpd does not support this
> newer API
>
> - serf currently is now at version 1.3.9 (August 2016) providing stable
> APIs. There is still some basic maintenance activity in the serf project,
> for instance for supporting newer scons build tool versions or support for
> OpenSSL 1.1.0.
>
> I do not actually know what the serf support adds to httpd, it seems mostly
> some "SerfCluster" feature for mod_proxy. There's no docs and some comments
> in the code indicate the impl is not complete. SVN logs point to the same
> direction.
>
> Paul Querna wrote in his 2009 svn commit log message:
>
> Work in Progress.
>
> =
> Add Clustered proxying support to mod_serf, by using the heartbeats system.
>
> No preconfiguration of cluster members is needed.
>
> Just a config like this:
> SerfCluster sweet heartbeat file=/var/cache/apache/hb.dat
> SerfCluster sour heartbeat file=/var/cache/apache/cluster2.dat
> 
>   SerfPass cluster://sweet
> 
> 
>   SerfPass cluster://sour
> 
>
> The location of all possible destination servers is provided by a new
> providers interface, that includes configuration checking of the arguments
> to the SerfCluster command, solving one of the worst problems with the
> mod_proxy load balancer subsystem.
> ===
>
> I suggest we pull the serf dependent code if we can no find a maintainer for
> it. Any comments? Anyone interested in actually updating it and making it
> work?
>
> Regards,
>
> Rainer

Too many knobs

[Paul Querna]

Saw this today, and noticed they used httpd as one of the projects they
collected data about:

http://neverworkintheory.org/2016/06/09/too-many-knobs.html
http://cseweb.ucsd.edu/~tixu/papers/fse15.pdf

Hard to make a quick conclusion, but I do believe in the general statement
of enumerations > numeric config options and having good defaults.

Re: TLS session ticket key (shared) renewal

[Paul Querna]

On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic <ylavic@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna <p...@querna.org> wrote:
> > My thought was to add support for either multiple files, or multiple
> values
> > in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt
> from
> > any of the known keys, and have a setting (or the first loaded key)
> would be
> > used to encrypt all new keys.  This would allow for rotation in a
> reasonable
> > manner.
>
> That's indeed a great improvement on what we have now, and actually
> looks like you first introduced it in r1200040 :)
> Why was it not kept that way?
>
> We'll still need a (graceful) restart to renew the keys, though.
>

(unix mpms) Having the a process (mpm_register_timed_callback? other
hooks?) re-read
the file periodically or on change, and set them set it in a slot mem is
reasonable, but not the behavior of almost any other file reference in
httpd... so the pattern of graceful is how most things work, I can't figure
out why session tickets are worth an exception to this pattern?


> Also, it seems there is interest in sharing the keys accross different
> instances/machines, is a file (unless on something like an NFS mount)
> an option here?
>

Most large scale deployments have configuration management or other
techniques to synchronize secret values across many machines;  I don't
think we should go overboard in building a network transport for session
ticket secrets.

Re: TLS session ticket key (shared) renewal

[Paul Querna]

My thought was to add support for either multiple files, or multiple values
in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt
from any of the known keys, and have a setting (or the first loaded key)
would be used to encrypt all new keys.  This would allow for rotation in a
reasonable manner.

On Fri, Mar 18, 2016 at 6:55 AM, Yann Ylavic  wrote:

> Currently this can be done by using a (shared) SSLSessionTicketKeyFile
> and gracefuly restarting httpd instances, but there is room for
> improvements here.
>
> Thoughts?
>

Re: XSLT filter for httpd

[Paul Querna]

On Mon, Oct 19, 2015 at 7:54 AM, Nick Kew  wrote:
> On Mon, 19 Oct 2015 15:39:06 +0200
> Graham Leggett  wrote:
>
>> > Note, mod_transform is GPL.  Originally my decision when I released
>> > its earlier predecessor, before I was part of the dev@httpd team.
>> > I'd be happy to re-license it as Apache, and I don't think
>> > any of my co-developers would object.
>>
>> I’ve been using mod_transform v0.6.0 for a while, and have wanted to develop 
>> it further. It would be a great starting point.
>
> I have a distant recollection of consulting Paul and Edward about
> re-licensing, then dropping the ball on it.  IIRC the outcome was,
> they were both happy to re-license, but there had also been one
> or two third-party patches raising a questionmark over whether we
> should consult anyone else.
>
> Cc: Paul.  Do you recollect that?  You still in contact with Edward?

I have no objections to relicensing mod_transform, Adding Edward and
Christian, the only other people with commits in afaik:

https://github.com/OutOfOrder/mod_transform/commits/master

 I'm not sure I believe in belongs in HTTP Server project itself, I
think it has had a fine life as an external module, and github is
doing fine for basic maintenance, but I'll bow to people with energy
if y'all really want it under the ASF domain.

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

[Paul Querna]

It seems reasonable to focus on ALPN support, and generally dropping
NPN from trunk.  NPN is already on a decline, and won't be used going
forward.

On Thu, Apr 2, 2015 at 12:44 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
 Any reason to differ from trunk in 2.4?

 The people using spdy already in a 2.4 will most likely have the NPN patch 
 deployed, so they'll have it easy with the trunk changes. The only one using 
 the alpn patch, I know of, is myself in mod_h2. And that has already been 
 adapted.

 So, I myself see no reason to not bring the trunk change into 2.4.

 Am 01.04.2015 um 22:33 schrieb Jim Jagielski j...@jagunet.com:

 Yeah, I agree. Right now, trunk pretty much uses

   #ifdef HAVE_TLS_ALPN
   blah blah
   #endif
   #ifdef HAVE_TLS_NPN
   blah2 blah2
   #endif

 Instead of

   #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)

 so that ripping out NPN would be easier. The question is
 which to use for 2.4...

 On Apr 1, 2015, at 1:59 PM, Stefan Eissing stefan.eiss...@greenbytes.de 
 wrote:

 Well, I took the trunk version, diffed to 2.4.12 and made a patch for my 
 sandbox build (removed the non alpn/npn parts). That works for mod_h2 after 
 adding callbacks for the npn stuff.

 I have no real pref to keep npn and alpn separate or not. my thought when 
 merging these was that npn will go away rather soon as alpn is supposed to 
 replace it and is afaik the cryptographically more secure way (i think npn 
 is prone to mitm downgrade attacks).

 cheers,
 Stefan



 Am 01.04.2015 um 19:28 schrieb Jim Jagielski j...@jagunet.com:

 Yeah, there is some overlap which I'm trying to grok,
 since trunk had NPN but not ALPN, so I tried to have the
 ALPN stuff self-contained. But not sure if that's the best
 way since, for example, alpn_proposefns is adjusted
 in ssl_callback_AdvertiseNextProtos(), but that is a
 NPN only function in trunk, so it uses npn_proposefns.

 I'm thinking that in trunk we shouldn't think of
 NPN and ALPN as distinct.

 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:

 Hi Stefan,

 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,

 today I converted your commit to a path on 2.4.12 and tested it with 
 mod_h2. All fine!

 Then I got a trouble report that alpn negotiation always selected 
 http/1.1 unless SSLAlpnPreference configured something else. This is 
 due to the deterministic ordering and http/1.1.  h2. So, I made a 
 slight modification, attached below.

 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in 
 mod_ssl trunk and therefore was not applied. In your attachment, there 
 was some code for sorting in ssl_callback_AdvertiseNextProtos() which 
 IMHO does not exist in trunk. Is that part necessary?

 A second difference: your original addition to ssl_engine_io.c had the 
 NPN and the ALPN parts merged in the same code block. In trunk those are 
 now two separate pieces coming after each other.

 --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0 
 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }

 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
 * 0 gives same precedence, 0 means proto1 is prefered.
 */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
   i += plen;
   }

 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
   proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}

   if (sslconn-alpn_proposefns != NULL) {
   /* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
   }

   if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are 
 supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is 
 always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
   }

   /* Now select the most preferred protocol from 

Re: apr_pollcb

[Paul Querna]

right, libuv[1] is a good example of an IO completion API[2] that works
across both epoll/kqueue and IOCP.  There have been a couple offhand
discussions about libuv on httpd-dev, but no one is clamoring for adoption.

APR currently has no such abstraction.

pollcb was added to provide a polling API that was lock free, allowed
cross-thread addition and didn't keep extra data structures around for N
sockets under management.  (this contrasts to APR's pollset which has
locks, uses a couple RINGs of structures to keep track of things, etc)


[1] - https://github.com/libuv/libuv
[2] - http://nikhilm.github.io/uvbook/filesystem.html#buffers-and-streams


On Thu, Mar 12, 2015 at 3:40 PM, Ivan Zhakov i...@visualsvn.com wrote:

 On 9 March 2015 at 20:04, Jim Jagielski j...@jagunet.com wrote:
  As far as I can tell, there are no real consumers of apr_pollcb_*()
  other than Motorz (and Simple)... Not sure, but it looks like the
  pollcb stuff may be lagging, since I'm getting some weird behavior
  when using that impl. So I'll likely be moving Motorz off of
  pollcb and use the traditional impl which has been proven in
  Event.
 

 I'd like to share some thoughts about pollcb as Windows developer.
 Most efficient way to handle a lot of connections on Windows is I/O
 completion ports  (IOCP). They are like epoll, but different. Here is
 good writeup about difference [1]. In short: IOCP provides
 notification when I/O completes, while epoll provides notifications
 when socket is ready to perform I/O operation. It would require
 additional buffer to implement pollcb using IOCP on Windows. Or
 APR/HTTPD should have different abstraction that is responsible for
 I/O and waiting for completion.

 [1]
 http://www.ulduzsoft.com/2014/01/practical-difference-between-epoll-and-windows-io-completion-ports-iocp/

 --
 Ivan Zhakov

Re: apr_pollcb

[Paul Querna]

Can you describe lagging in more detail?

None of the poll related code has a high rate of change (except for the
relatively new z/OS backend):

https://github.com/apache/apr/tree/trunk/poll/unix

Also are you looking specifically on Linux? (epoll backend?) or others

On Mon, Mar 9, 2015 at 11:04 AM, Jim Jagielski j...@jagunet.com wrote:

 As far as I can tell, there are no real consumers of apr_pollcb_*()
 other than Motorz (and Simple)... Not sure, but it looks like the
 pollcb stuff may be lagging, since I'm getting some weird behavior
 when using that impl. So I'll likely be moving Motorz off of
 pollcb and use the traditional impl which has been proven in
 Event.

Re: What's need for http/2.0?

[Paul Querna]

httpd side:

serf to me is the wrong question.

http/2.0 in the simplest implementation is just another protocol to
httpd.  We have the constructs to handle it, kinda.  Improvements to
async support in various bits will help.

However our constructs about requests and connections (and their
pools) are still grounded in the http1 mindset. http2 should challenge
us to do real multiplexing of requests.  I don't believe our existing
hierarchy of pools deals well with the complexities of lifetime
management of data in this multiplexed world, especially when you
multiply that multiplexed nature of an http2 proxy (or reverse proxy)
with its own outbound connections and requests.

Additionally there are 'new' things that we don't deal with today, like:

* Server Push
* Stream Prioritization
* Flow Control integration into proxy use cases

Things like flow control and stream priorities interact poorly with
the output current filter API and model -- calling the next function
with a brigade, even if it wants you to try again, every caller has to
deal with these complexities of back pressure -- I'd love to have more
open discussion about ideas here.

http2 will be around for another 20+ years, I'd challenge us to think
about it as the default case, and http1 as a fallback case that we
still support well, but the architecture and APIs are optimized for
the future case.


On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote:
 APR:
 Considering that before we know it, http/2.0 will
 be here, and ignoring httpd for the time being,
 what features/additions do we see as being needed
 to support http/2.0 from an APR library level? How do
 we compare w/ libuv, for example? How event-aware
 should APR be, ala libevent?

 HTTPD:
 From the httpd point of view, what does serf
 provide for us to help us get to http/2.0? Should
 we make it a requirement? Are there things we
 need that, instead of making them part of httpd,
 should really be in APR instead? What other external
 libs should we be leveraging?

Re: What's need for http/2.0?

[Paul Querna]

On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote:
 APR:
 Considering that before we know it, http/2.0 will
 be here, and ignoring httpd for the time being,
 what features/additions do we see as being needed
 to support http/2.0 from an APR library level? How do
 we compare w/ libuv, for example? How event-aware
 should APR be, ala libevent?

On APR:  I mean. It's a platform layer over OS syscalls.  it works.
But... Having has a hand in early libuv development:

libuv is fundamentally different -- everything is event based,
anything that isn't able to be 'natively evented' into the OS event
loop is dispatched to a thread pool.  __This is nice because it gives
you a constant abstraction to IO operations, not just the OS
syscalls.__

APR lacks this POV.  This has trade offs.  Most commonly, File IO, as
you need to do a blocking IO operation in another thread, which means
you add a context switch or three to do IO.  However with the changes
to framing in http2, the days of just sendfile()'ing a file and
blocking a thread are basically over, so maybe its not a huge deal in
the end.

As libuv was designed to be embedded in garbage collected languages,
libuv also does not adopt pools.  From my experience pools also tend
to be harder to keep fine grained in most evented models, but this
doesn't mean they couldn't be layered on top with care.

My POV: I'd just use libuv, and port any APR-Util code to a library on
top of libuv if it is needed.  I'd probably keep pools for module
level code using requests, but I'm unsure about connection pools
honestly.

Re: apr_skiplist (current) implementation wrt mpm_event (timers, keepalives?)

[Paul Querna]

- I think it is good to fix this behavior, using only the global
keepalive timeout was definitely a choice I (?) made when doing it.

- Skiplists seem generally acceptable for storing this data.
Alternatively a BTree with in order iteration would be competitive..
but, meh, either will be fine.

- I'd love if we could seek ways to unify the timeout queues inside
the Event MPM.  Right now we have:
  * keepalive_q
  * write_completion_q
  * linger_q
  * short_linger_q

Maybe making a single structure for all timeouts, with a baton / type
enum for any extra data or the function to call?

For example `write_completion_q` is mapped to global server TimeOut
directive.. so same bug as KeepAliveTimeOut.

Making just the keepalive queue a skiplist, and leaving the others...
seems less than optimal in my view.

- No comment on fixing APR Skiplists :)

On Thu, May 22, 2014 at 5:04 AM, Yann Ylavic ylavic@gmail.com wrote:
 Hello,

 while working on
 https://issues.apache.org/bugzilla/show_bug.cgi?id=56226 for a
 possible way to use vhost's KeepAliveTimeout with mpm_event (by using
 a skiplist instead of the actual keepalive queue), I realized that
 apr_skiplists do not accept multiple values per key (unlike apr_table
 for example, or std::multimap).

 AFAICT this is only an implementation choice, which could be changed
 with something like :
 Index: tables/apr_skiplist.c
 ===
 --- tables/apr_skiplist.c(revision 1595631)
 +++ tables/apr_skiplist.c(working copy)
 @@ -406,11 +406,7 @@ APR_DECLARE(apr_skiplistnode *) apr_skiplist_inser
  if (m-next) {
  compared = comp(data, m-next-data);
  }
 -if (compared == 0) {
 -free(stack);/* OK. was malloc'ed */
 -return 0;
 -}
 -if ((m-next == NULL) || (compared  0)) {
 +if (compared  0) {
  if (ch = nh) {
  /* push on stack */
  stack[stacki++] = m;

 (probably with a new apr_skiplist_set_multi() which would make it 
 controlable).

 The skiplist's key used for timers by mpm_event is the expiration time
 (in microseconds), I think the issue is multiple timers created at the
 same time (which may happen when different threads request a timer,
 eg. with event_register_[timed|socket]_callback).
 In that case, none but the first one will be inserted in the skiplist
 (and hence known by listener).

 Shouldn't skiplists accept multiple values for the same key by default?

 For 56226, if we were to replace the actual keepalive queue with a
 skiplist, the proposed patch suffers the same issue.
 If however the current behaviour (and speed) of using the base
 server's KeepaliveTimeout for all the vhosts is a choice, I think it
 should at least be documented on the KeepAliveTimeout directive, as a
 limitation for mpm_event.

 Regards,
 Yann.

Re: mod_spdy

[Paul Querna]

Right now it is a beast of C++ code.  I'd vote separate repo, take
learnings from it as a basis for HTTP/2.0.

On Wed, Apr 30, 2014 at 9:51 AM, Jim Jagielski j...@jagunet.com wrote:
 I'm thinking... we should likely create a sep mod_spdy
 repo (ala http://svn.apache.org/viewvc/httpd/mod_fcgid/)
 instead of it being in/under trunk.

 What do you say?

Re: SSL and NPN

[Paul Querna]

Tend to agree with the other comments, NPN by itself will be
deprecated quickly, ALPN is the future.  I'd vote for a series of back
ports that include both NPN and ALPN together.

On Mon, Apr 28, 2014 at 2:50 PM, Jim Jagielski j...@jagunet.com wrote:
 Any reason to NOT include

 http://svn.apache.org/viewvc?view=revisionrevision=1332643
 http://svn.apache.org/viewvc?view=revisionrevision=1487772

 in 2.4??

Re: breach attack

[Paul Querna]

On Fri, Aug 9, 2013 at 12:11 AM, Ruediger Pluem rpl...@apache.org wrote:


 Stefan Fritsch wrote:
 Am Dienstag, 6. August 2013, 10:24:15 schrieb Paul Querna:
 1) Disabling HTTP compression
 2) Separating secrets from user input
 3) Randomizing secrets per request
 4) Masking secrets (effectively randomizing by XORing with a random
 secret per request)
 5) Protecting vulnerable pages with CSRF
 6) Length hiding (by adding random amount of bytes to the responses)
 7) Rate-limiting the requests


 Many of these are firmly in the domain of an application developer,
 but I think we should work out if there are ways we can either
 change default configurations or add new features to help
 application developers be successful:

 IMNSO, we are way past the point where we should patch up even more
 issues that are caused by the broken security module of web browsers.
 Instead, browsers vendors should fix this issue, for example by
 offering a way to easily opt out of sending credentials with cross-
 domain requests (maybe analogous to Strict Transport Security).

 I am against putting any mitigation measures into httpd that adversely
 affect normal use, like adding chunk extensions that will likely break
 lots of clients, or like making mod_deflate much less efficient.
 Though if somebody comes up with a clever scheme that has no negative
 side effects, that would be of course fine. Or if we add some rate
 limiting facility that would be useful for many purposes.



 +1. Well put.


I strongly disagree.

We are a component in an ecosystem that consists of Browsers and Servers.

We are part of that broken security model, even if the root cause is
from the browsers.

In this case, I don't know if any of the proposed mitigations help;
I'd love to have an easy way to validate that, so we could bring data
to the discussion:  If it increases the attack by multiple hours, and
causes a 1% performance drop, isn't that the kind of thing that is
useful?

We should strive as a community help, not to just throw the browsers
under the bus.

Re: [PATCH] systemd socket activation

[Paul Querna]

Committed to trunk in r1511033.

On Wed, Jul 24, 2013 at 12:00 AM, Jan Kaluža jkal...@redhat.com wrote:
 On 07/21/2013 11:14 PM, Paul Querna wrote:

 Hiya Y'all, long time no patches :-)

 Attached is a patch that would let httpd use systemd's socket
 activation feature:
http://0pointer.de/blog/projects/socket-activation.html

 Also online here:

 https://github.com/pquerna/httpd/compare/trunk...systemd_socket_activation


 Hi,

 I have tried the patch on F18 with httpd-2.4.6 and it works as expected. I
 really like it :).

 Regards,
 Jan Kaluza


 It isn't particularly pretty;  Mostly it is working within how
 listener code already works.  You can test it yourself very easily
 using something like:

 /usr/lib/systemd/systemd-activate -l 0.0.0.0:8080 -l 9080
 /usr/local/httpd-dev/bin/httpd -DFOREGROUND

 You'll note it works with multiple listeners.  I've been testing it on
 Fedora 19, and it seems fine there.

 Now, the patch is not part of mod_systemd.  This is mostly because the
 listener.c code isn't exactly friendly to a non-core module messing
 around with the listeners.  I'd definitely be +1 to a larger
 refactoring of listen.c, but not sure I have the time / energy to head
 that up.

 If there aren't any objections I'll commit it into trunk in a few days,

 Thanks,

 Paul

breach attack

[Paul Querna]

Hiya,

Has anyone given much thought to changes in httpd to help mitigate the
recently publicized breach attack:

http://breachattack.com/

From an httpd perspective, looking at the mitigations
http://breachattack.com/#mitigations

1) Disabling HTTP compression
2) Separating secrets from user input
3) Randomizing secrets per request
4) Masking secrets (effectively randomizing by XORing with a random
secret per request)
5) Protecting vulnerable pages with CSRF
6) Length hiding (by adding random amount of bytes to the responses)
7) Rate-limiting the requests


Many of these are firmly in the domain of an application developer,
but I think we should work out if there are ways we can either change
default configurations or add new features to help application
developers be successful:

1) Has anyone given any thought to changing how we do chunked
encoding?Chunking is kinda like arbitrary padding we an insert
into a response, without having to know anything about the actual
content of the response.  What if we increased the number of chunks we
create, and randomly placed them -- this wouldn't completely ruin some
of the attacks, but could potentially increase the number of requests
needed significantly. (We should figure out the math here?  How many
random chunks of how big are an effective mitigation?)

2) Disabling TLS Compression by default, even in older versions.
Currently we changed the default to SSLCompression off in =2.4.3, I'd
like to see us back port this to 2.2.x.

3) Disable mod_default compression for X content types by default on
encrypted connections.  Likely HTML, maybe JSON, maybe Javascript
content types?

Thoughts? Other Ideas?

Thanks,

Paul

Re: breach attack

[Paul Querna]

On Tue, Aug 6, 2013 at 10:32 AM, Eric Covener cove...@gmail.com wrote:
 On Tue, Aug 6, 2013 at 1:24 PM, Paul Querna p...@querna.org wrote:
 Hiya,

 Has anyone given much thought to changes in httpd to help mitigate the
 recently publicized breach attack:

 http://breachattack.com/

 From an httpd perspective, looking at the mitigations
 http://breachattack.com/#mitigations

 1) Disabling HTTP compression
 2) Separating secrets from user input
 3) Randomizing secrets per request
 4) Masking secrets (effectively randomizing by XORing with a random
 secret per request)
 5) Protecting vulnerable pages with CSRF
 6) Length hiding (by adding random amount of bytes to the responses)
 7) Rate-limiting the requests


 Many of these are firmly in the domain of an application developer,
 but I think we should work out if there are ways we can either change
 default configurations or add new features to help application
 developers be successful:

 1) Has anyone given any thought to changing how we do chunked
 encoding?Chunking is kinda like arbitrary padding we an insert
 into a response, without having to know anything about the actual
 content of the response.  What if we increased the number of chunks we
 create, and randomly placed them -- this wouldn't completely ruin some
 of the attacks, but could potentially increase the number of requests
 needed significantly. (We should figure out the math here?  How many
 random chunks of how big are an effective mitigation?)

 Another option in this neighborhood is small/varying deflate blocks.
 But that probably limits the usefulness of deflate to the same extent
 that it helps.  The idea is to make it less likely that the user input
 and secret get compressed together.


 2) Disabling TLS Compression by default, even in older versions.
 Currently we changed the default to SSLCompression off in =2.4.3, I'd
 like to see us back port this to 2.2.x.

 I think it recently made it to 2.2.x, post the last release.


 3) Disable mod_default compression for X content types by default on
 encrypted connections.  Likely HTML, maybe JSON, maybe Javascript
 content types?

 In the code, or default conf / manual? It's the cautious thing to do,
 but I'm not yet sure if making everyone opt back in would really mean
 much (e.g. what number would give their app the required scrutiny
 before opting back in)

In the code.

Configurations take order of magnitude more years to trickle down to
vendors compared to a code change... :-)

Re: breach attack

[Paul Querna]

On Tue, Aug 6, 2013 at 10:38 AM, Steffen i...@apachelounge.com wrote:

 Good instructive and advisable config:

 https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy


Well, Forward-Secrecy is really about the NSA capturing your traffic
and decrypting it later;  the Breach attack stuff is about a chosen
plaintext attack on compressed response bodies -- afaik they have not
overlapping mitigations?

But in general, we should rev our defaults in configuration to help
with all of the above :)



 On Tuesday 06/08/2013 at 19:24, Paul Querna  wrote:

 Hiya,

 Has anyone given much thought to changes in httpd to help mitigate the
 recently publicized breach attack:

 http://breachattack.com/

 From an httpd perspective, looking at the mitigations
 http://breachattack.com/#mitigations

 1) Disabling HTTP compression
 2) Separating secrets from user input
 3) Randomizing secrets per request
 4) Masking secrets (effectively randomizing by XORing with a random
 secret per request)
 5) Protecting vulnerable pages with CSRF
 6) Length hiding (by adding random amount of bytes to the responses)
 7) Rate-limiting the requests


 Many of these are firmly in the domain of an application developer,
 but I think we should work out if there are ways we can either change
 default configurations or add new features to help application
 developers be successful:

 1) Has anyone given any thought to changing how we do chunked
 encoding?Chunking is kinda like arbitrary padding we an insert
 into a response, without having to know anything about the actual
 content of the response.  What if we increased the number of chunks we
 create, and randomly placed them -- this wouldn't completely ruin some
 of the attacks, but could potentially increase the number of requests
 needed significantly. (We should figure out the math here?  How many
 random chunks of how big are an effective mitigation?)

 2) Disabling TLS Compression by default, even in older versions.
 Currently we changed the default to SSLCompression off in =2.4.3, I'd
 like to see us back port this to 2.2.x.

 3) Disable mod_default compression for X content types by default on
 encrypted connections.  Likely HTML, maybe JSON, maybe Javascript
 content types?

 Thoughts? Other Ideas?

 Thanks,

 Paul

Re: [PATCH] Make error logging modular

[Paul Querna]

Hello Jan,

Is there any reason we shouldn't do this in trunk?

The patches and features seem generally correct to me with a cursory review.

Thanks,

Paul

On Mon, May 27, 2013 at 3:23 AM, Jan Kaluža jkal...@redhat.com wrote:
 Hi,

 last week I was trying to write my own module to log error_log to
 systemd-journal [1] and I've found out that with the current error_log code,
 it's not possible to do that properly.

 I was able to use error_log hook, but there is no way to disable creation
 of ErrorLog file (One can set it to /dev/null, but httpd will still
 write data to it without any reason). Syslog logger fixes that by hardcoding
 syslog methods in log.c/core.c, but I don't think that's the right thing to
 do with journald.

 Therefore, I've created following patches:
 http://people.apache.org/~jkaluza/patches/logging/

 Their descriptions should be clear from their names, but I will describe
 them briefly here too.

 Patch 0001 declares ap_errorlog_provider which can be implemented by module
 providing error_log logger. Admin can later define ErrorLog provider arg
 to choose particular errorlog provider. Old syntax still works and the
 change is backward compatible. This patch also removes syslog logging from
 log.c (it is moved to newly created mod_syslog.c in next patch)

 Patch 0002 creates mod_syslog.c which uses the new API to implement syslog
 logging. It works the same way as the version in log.c I removed in previous
 patch, but it's in separate module.

 Patch 0003 shows how mod_journald.c can use the existing API. This module
 works well with systemd-journal, but unfortunately the performance of
 systemd-journal daemon is poor so far [2], but I presume it will be fixed
 and the module will be usable for general use in the future. There is
 probably no real benefit in accepting this last patch right now. It's here
 to only show why the previous two patches are useful.

 Note that this is my first bigger patch touching httpd core, so feel free to
 correct my possible mistakes... :)

 [1] http://0pointer.de/blog/projects/journalctl.html
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=963620
 [patches] http://people.apache.org/~jkaluza/patches/logging/

 Regards,
 Jan Kaluza

[PATCH] systemd socket activation

[Paul Querna]

Hiya Y'all, long time no patches :-)

Attached is a patch that would let httpd use systemd's socket
activation feature:
  http://0pointer.de/blog/projects/socket-activation.html

Also online here:
  https://github.com/pquerna/httpd/compare/trunk...systemd_socket_activation

It isn't particularly pretty;  Mostly it is working within how
listener code already works.  You can test it yourself very easily
using something like:

   /usr/lib/systemd/systemd-activate -l 0.0.0.0:8080 -l 9080
/usr/local/httpd-dev/bin/httpd -DFOREGROUND

You'll note it works with multiple listeners.  I've been testing it on
Fedora 19, and it seems fine there.

Now, the patch is not part of mod_systemd.  This is mostly because the
listener.c code isn't exactly friendly to a non-core module messing
around with the listeners.  I'd definitely be +1 to a larger
refactoring of listen.c, but not sure I have the time / energy to head
that up.

If there aren't any objections I'll commit it into trunk in a few days,

Thanks,

Paul


systemd-socket-activation.patch
Description: Binary data

c conf 2012

[Paul Querna]

Heya,

A friend of mine is helping organizing the first C Conf:

  http://www.cconf.org/

I think it could be a very interesting conference for those of us that
still enjoy coding C :-)

I think it would be great if we could get a few talks submitted about
APR and HTTPD too, two projects with a long C history.  I personally
plan on being there if anyone wants to meet up then

-Paul

Re: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: config3.m4 equeue.c equeue.h event.c

[Paul Querna]

On Wed, Nov 16, 2011 at 1:20 AM, Rüdiger Plüm
ruediger.pl...@vodafone.com wrote:


  Original-Nachricht 
 Betreff: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: 
 config3.m4 equeue.c equeue.h event.c
 Datum: Tue, 15 Nov 2011 15:51:04 GMT
 Von: pque...@apache.org

 Author: pquerna
 Date: Tue Nov 15 15:51:03 2011
 New Revision: 1202257

 URL: http://svn.apache.org/viewvc?rev=1202257view=rev
 Log:
 Create a new lock free circular queue, and use it in the EventMPM to remove 
 the timeout mutex
 that was wrapping both timeout queue operations and pollset operations.

 Added:
 httpd/httpd/trunk/server/mpm/event/equeue.c   (with props)
 httpd/httpd/trunk/server/mpm/event/equeue.h   (with props)
 Modified:
 httpd/httpd/trunk/server/mpm/event/config3.m4
 httpd/httpd/trunk/server/mpm/
 event/event.c

 Modified: httpd/httpd/trunk/server/mpm/event/config3.m4
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/equeue.c?rev=1202257view=auto
 ==
 --- httpd/httpd/trunk/server/mpm/event/equeue.c (added)
 +++ httpd/httpd/trunk/server/mpm/event/equeue.c Tue Nov 15 15:51:03 2011
 @@ -0,0 +1,125 @@
 +/* Licensed to the Apache Software Foundation (ASF) under one or more
 + * contributor license agreements.  See the NOTICE file distributed with
 + * this work for additional information regarding copyright ownership.
 + * The ASF licenses this file to You under the Apache License, Version 2.0
 + * (the License); you may not use this file except in compliance with
 + * the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an AS IS BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +
 +#include equeue.h
 +
 +#include apr_atomic.h
 +#include sched.h
 +
 +struct ap_equeue_t {
 +apr_uint32_t nelem;
 +apr_size_t elem_size;
 +uint8_t *bytes;
 +volatile apr_uint32_t writeCount;
 +volatile apr_uint32_t readCount;
 +};
 +
 +
 +static APR_INLINE apr_uint32_t count_to_index(ap_equeue_t *eq, apr_uint32_t 
 count)
 +{
 +return (count  (eq-nelem - 1));
 +}
 +
 +static APR_INLINE void* index_to_bytes(ap_equeue_t *eq, apr_uint32_t idx)
 +{
 +apr_size_t offset = idx * eq-elem_size;
 +return (void*)eq-bytes[offset];
 +}
 +
 +static APR_INLINE apr_uint32_t nearest_power(apr_uint32_t num)
 +{
 +apr_uint32_t n = 1;
 +while (n  num) {
 +n = 1;
 +}
 +
 +return n;
 +}
 +
 +#if 0
 +static void dump_queue(ap_equeue_t *eq)
 +{
 +apr_uint32_t i;
 +
 +fprintf(stderr, dumping %p\n, eq);
 +fprintf(stderr,   nelem:   %u\n, eq-nelem);
 +fprintf(stderr,   esize:   %APR_SIZE_T_FMT\n, eq-elem_size);
 +fprintf(stderr,   wcnt:%u\n, eq-writeCount);
 +fprintf(stderr,   rcnt:%u\n, eq-writeCount);
 +fprintf(stderr,   bytes:   %p\n, eq-bytes);
 +for (i = 0; i  eq-nelem; i++) {
 +fprintf(stderr, [%u] = %p\n, i, index_to_bytes(eq, i));
 +}
 +
 +fprintf(stderr, \n);
 +fflush(stderr);
 +}
 +#endif
 +
 +apr_status_t
 +ap_equeue_create(apr_pool_t *p, apr_uint32_t nelem, apr_size_t elem_size, 
 ap_equeue_t **eqout)
 +{
 +ap_equeue_t *eq;
 +
 +*eqout = NULL;
 +
 +eq = apr_palloc(p, sizeof(ap_equeue_t));
 +eq-bytes = apr_palloc(p, (1 + nelem) * elem_size);
 +eq-nelem = nearest_power(nelem);
 +eq-elem_size = elem_size;
 +eq-writeCount = 0;
 +eq-readCount = 0;
 +*eqout = eq;
 +
 +return APR_SUCCESS;
 +}
 +
 +void *
 +ap_equeue_reader_next(ap_equeue_t *eq)
 +{
 +if (apr_atomic_read32(eq-writeCount) == eq-readCount) {
 +return NULL;
 +}
 +else {
 +apr_uint32_t idx = count_to_index(eq, 
 apr_atomic_inc32(eq-readCount));
 +return index_to_bytes(eq, idx);
 +}
 +}
 +
 +void *
 +ap_equeue_writer_value(ap_equeue_t *eq)
 +{
 +apr_uint32_t idx;
 +
 +while (1) {
 +apr_uint32_t readCount = apr_atomic_read32(eq-readCount);
 +
 +if (count_to_index(eq, eq-writeCount + 1) != count_to_index(eq, 
 readCount)) {
 +break;
 +}
 +/* TODO: research if sched_yield is even worth doing  */
 +sched_yield();
 +}
 +
 +idx = count_to_index(eq, eq-writeCount);
 +return index_to_bytes(eq, idx);
 +}

 I assume that only a single thread tries write operations on this queue, 
 correct?
 Otherwise it seems unsafe if another thread calls
 ap_equeue_writer_value in parallel as it would return the same slot until
 ap_equeue_writer_onward was called.

Correct, it only supports a single writer and  a single reader, which
lets you get away with only a few atomic operations and no 

Re: svn commit: r1202255 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c

[Paul Querna]

On Wed, Nov 16, 2011 at 2:44 AM, Rainer Jung rainer.j...@kippdata.de wrote:
 On 15.11.2011 20:57, Jeff Trawick wrote:

 On Tue, Nov 15, 2011 at 2:32 PM, William A. Rowe Jr.
 wr...@rowe-clan.net  wrote:

 On 11/15/2011 12:33 PM, Stefan Fritsch wrote:

 On Tuesday 15 November 2011, Paul Querna wrote:

 On Tue, Nov 15, 2011 at 9:17 AM, Stefan Fritschs...@sfritsch.de

 wrote:

 On Tue, 15 Nov 2011, pque...@apache.org wrote:

 Author: pquerna
 Date: Tue Nov 15 15:49:19 2011
 New Revision: 1202255

 URL: http://svn.apache.org/viewvc?rev=1202255view=rev
 Log:
 disable mod_reqtimeout if not configured

 Why that? We have just changed the default to be enabled in
 r1199447 and several developers at the hackathon agreed to this
 change.

 Didn't know it was discussed in depth at the hackathon, and there
 wasn't any discussion on the list

 It showed up quite quickly in my profiling of the Event MPM,
 because every pull/push on the filters would cause a
 apr_time_now() call.

 I don't really like that just by loading the module, it changes the
 behavior and performance of the server so drastically.

 It only acts on reads from the client. Normal non-POST requests arrive
 in one or two packets, which would mean approx. 3 additional
 apr_time_now calls per request. I haven't done benchmarks, but I can't
 imagine that this has a drastic impact on performance. And if it costs
 1-2%, then that's a small cost compared to the impact of slowloris
 type attacks which eat lots of memory.

 The general intention of the recent changes in default configs and
 module selection/loading was to make it easier to only load those
 modules that are really needed, have a reasonable default config, and
 have the compiled-in default values be the same as those in the
 example config files.

 Which means, build by default, disable by default.  I think that keeps
 everyone happy.  When abuse arrives, it's trivial to load.

 Timeout 60 isn't nearly as bad as the old Timeout 300 that is probably
 still in wide use, but mod_reqtimeout can provide a much more
 reasonable out of the box configuration.  I think we should keep it in
 place by default.

 +1


What I am really opposed to is that the LoadModule causes such a
degradation in performance.

I am 100% +1 to adding conf commands to the default configuration in
the httpd.conf, but what I do not like is that having just a
LoadModule with nothing else causes reqtimeout to do work.  It is too
trivial for people to have accidental load modules in many distros.

setting TZ env var

[Paul Querna]

So, I was looking at all the system calls we make in a single request,
and comparing it to nginx.

We were actually pretty close, baring supporting our features like
htaccess, there was only one thing that stood out.

Glibc is opening, calling fstat twice, and then reading /etc/localtime
for every request:

[pid 31496]  0.51 open(/etc/localtime, O_RDONLY) = 8 0.14
[pid 31496]  0.41 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
...}) = 0 0.11
[pid 31496]  0.48 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
...}) = 0 0.10
[pid 31496]  0.48 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbd87efa000 0.13
[pid 31496]  0.40 read(8,
TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0...,
4096) = 118 0.15
[pid 31496]  0.51 lseek(8, -62, SEEK_CUR) = 56 0.11
[pid 31496]  0.34 read(8,
TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0...,
4096) = 62 0.11
[pid 31496]  0.48 close(8)  = 0 0.12


One way to fix this, is to set the TZ environment variable.

For example:
  
https://github.com/pquerna/httpd/commit/37e5815a70e88a733cd088398d016803146b545f

This specific patch has some issues, but is there any objections to
the concept of setting the timezone on process startup?

This single change gives about a 2% performance boost in my testing.

To merge to trunk I'd like to have it detect your active timezone,
instead of forcing UTC+0, but if you changed timezones on your
machine, you will need to restart httpd.

Thoughts?

Thanks,

Paul

Re: svn commit: r1200040 - in /httpd/httpd/trunk: CHANGES modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h

[Paul Querna]

On Sun, Nov 13, 2011 at 2:34 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 On 10.11.2011 00:37, pque...@apache.org wrote:
 Author: pquerna
 Date: Wed Nov  9 23:37:37 2011
 New Revision: 1200040

 URL: http://svn.apache.org/viewvc?rev=1200040view=rev
 Log:
 Add support for RFC 5077 TLS Session tickets.  This adds two new directives:

 * SSLTicketKeyFile: To store the private information for the encryption of 
 the ticket.
 * SSLTicketKeyDefault To set the default, otherwise the first listed token 
 is used.  This enables key rotation across servers.

 It's not completely clear to me how these two directives interact - what
 does first listed token relate to? Can multiple SSLTicketKeyFile
 directives appear within a VirtualHost?


Yes.

Maybe explaining it as such is easier to understand:

SSLTicketKeyFile basically gives you a list of possible decryption keys.

SSLTicketKeyDefault picks which one to use for encryption.  If
SSLTicketKeyDefault is not set, the first added decryption key is
used.


 --- httpd/httpd/trunk/CHANGES [utf-8] (original)
 +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Nov  9 23:37:37 2011
 @@ -1,6 +1,9 @@
                                                           -*- coding: utf-8 
 -*-
  Changes with Apache 2.3.16

 +  *) mod_ssl: Add support for RFC 5077 TLS Session tickets.
 +     [Paul Querna]

 This is somewhat misleading, I think. Session tickets are supported in
 mod_ssl as soon as you compile it against OpenSSL 0.9.8f or later (they
 default to on in OpenSSL, SSL_OP_NO_TICKET would have to be set
 otherwise). What your patch adds, OTOH, is allowing explicit control of
 the ticket encryption/decryption keys.

Sorry, this is correct.   Its not adding support to them in a single
cluster, its making them configurable / controlable by the user --
OpenSSL by default does generate random keys, but in a cluster of
servers this makes session tickets basically useless.

 Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1200040r1=1200039r2=1200040view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
 +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Wed Nov  9 23:37:37 2011
 @@ -79,6 +79,14 @@ static const command_rec ssl_config_cmds
      SSL_CMD_SRV(FIPS, FLAG,
                  Enable FIPS-140 mode 
                  (`on', `off'))
 +#ifdef HAVE_TLSEXT_TICKETS
 +    SSL_CMD_SRV(TicketKeyFile, TAKE2,
 +                Key file to use for encrypting and decrypting the client 
 ticket (RFC 5077) 
 +                (keyname '/path/to/file'))

 I suggest to add some info about the contents of these files (like 48
 random bytes in binary format). Also, the documentation of this
 directive should encourage users to regularly change these keys.

 Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1200040r1=1200039r2=1200040view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Wed Nov  9 23:37:37 
 2011
 @@ -200,6 +200,12 @@ static SSLSrvConfigRec *ssl_config_serve
      sc-fips                   = UNSET;
  #endif

 +#ifdef HAVE_TLSEXT_TICKETS
 +    sc-default_ticket_name = NULL;
 +    sc-default_ticket = NULL;
 +    sc-tickets = apr_array_make(p, 4, sizeof(modssl_ticket_t*));

 Maybe a stupid question, but I don't (yet) see the reason for using an
 array with four elements... could you perhaps shed some more light on this?

APR array make pre-allocates this much space.  If you use more than 4
elements, it needs to do another allocation.  If you use less than 4,
it will only allocate memory here.  It is not a limit.

 Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1200040r1=1200039r2=1200040view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Wed Nov  9 23:37:37 
 2011
 @@ -2067,3 +2067,94 @@ static int ssl_find_vhost(void *serverna
      return 0;
  }
  #endif
 +
 +#ifdef HAVE_TLSEXT_TICKETS
 +
 +#ifndef tlsext_tick_md
 +#ifdef OPENSSL_NO_SHA256
 +#define tlsext_tick_md       EVP_sha1
 +#else
 +#define tlsext_tick_md       EVP_sha256
 +#endif
 +#endif

 That's something which belongs into ssl_private.h, I think.


 As a general comment, I would like to see some guidelines in the
 documentation as to when an explicit configuration of TLS session ticket
 keys really makes sense - and how to create/maintain the key files, in
 this case. For a default standalone setup, people are still better off
 with using OpenSSL's

Re: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: config3.m4 equeue.c equeue.h event.c

[Paul Querna]

On Tue, Nov 15, 2011 at 9:25 AM, Rüdiger Plüm
ruediger.pl...@vodafone.com wrote:


  Original-Nachricht 
 Betreff: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: 
 config3.m4 equeue.c equeue.h event.c
 Datum: Tue, 15 Nov 2011 15:51:04 GMT
 Von: pque...@apache.org

 Author: pquerna
 Date: Tue Nov 15 15:51:03 2011
 New Revision: 1202257

 URL: http://svn.apache.org/viewvc?rev=1202257view=rev
 Log:
 Create a new lock free circular queue, and use it in the EventMPM to remove 
 the timeout mutex
 that was wrapping both timeout queue operations and pollset operations.

 Added:
 httpd/httpd/trunk/server/mpm/event/equeue.c   (with props)
 httpd/httpd/trunk/server/mpm/event/equeue.h   (with props)
 Modified:
 httpd/httpd/trunk/server/mpm/event/config3.m4
 httpd/httpd/trunk/server/mpm/
 event/event.c


 Added: httpd/httpd/trunk/server/mpm/event/equeue.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/equeue.c?rev=1202257view=auto
 ==
 --- httpd/httpd/trunk/server/mpm/event/equeue.c (added)
 +++ httpd/httpd/trunk/server/mpm/event/equeue.c Tue Nov 15 15:51:03 2011
 @@ -0,0 +1,125 @@
 +/* Licensed to the Apache Software Foundation (ASF) under one or more
 + * contributor license agreements.  See the NOTICE file distributed with
 + * this work for additional information regarding copyright ownership.
 + * The ASF licenses this file to You under the Apache License, Version 2.0
 + * (the License); you may not use this file except in compliance with
 + * the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an AS IS BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +
 +#include equeue.h
 +
 +#include apr_atomic.h
 +#include sched.h
 +
 +struct ap_equeue_t {
 +apr_uint32_t nelem;
 +apr_size_t elem_size;
 +uint8_t *bytes;
 +volatile apr_uint32_t writeCount;
 +volatile apr_uint32_t readCount;
 +};
 +
 +
 +static APR_INLINE apr_uint32_t count_to_index(ap_equeue_t *eq, apr_uint32_t 
 count)
 +{
 +return (count  (eq-nelem - 1));
 +}
 +
 +static APR_INLINE void* index_to_bytes(ap_equeue_t *eq, apr_uint32_t idx)
 +{
 +apr_size_t offset = idx * eq-elem_size;
 +return (void*)eq-bytes[offset];
 +}
 +
 +static APR_INLINE apr_uint32_t nearest_power(apr_uint32_t num)
 +{
 +apr_uint32_t n = 1;
 +while (n  num) {
 +n = 1;
 +}
 +
 +return n;
 +}
 +
 +#if 0
 +static void dump_queue(ap_equeue_t *eq)
 +{
 +apr_uint32_t i;
 +
 +fprintf(stderr, dumping %p\n, eq);
 +fprintf(stderr,   nelem:   %u\n, eq-nelem);
 +fprintf(stderr,   esize:   %APR_SIZE_T_FMT\n, eq-elem_size);
 +fprintf(stderr,   wcnt:%u\n, eq-writeCount);
 +fprintf(stderr,   rcnt:%u\n, eq-writeCount);
 +fprintf(stderr,   bytes:   %p\n, eq-bytes);
 +for (i = 0; i  eq-nelem; i++) {
 +fprintf(stderr, [%u] = %p\n, i, index_to_bytes(eq, i));
 +}
 +
 +fprintf(stderr, \n);
 +fflush(stderr);
 +}
 +#endif
 +
 +apr_status_t
 +ap_equeue_create(apr_pool_t *p, apr_uint32_t nelem, apr_size_t elem_size, 
 ap_equeue_t **eqout)
 +{
 +ap_equeue_t *eq;
 +
 +*eqout = NULL;
 +
 +eq = apr_palloc(p, sizeof(ap_equeue_t));
 +eq-bytes = apr_palloc(p, (1 + nelem) * elem_size);
 +eq-nelem = nearest_power(nelem);

 Shouldn't that be

 +eq-nelem = nearest_power(nelem);
 +eq-bytes = apr_palloc(p, eq-nelem * elem_size);


 instead? Otherwise we might allocate too few elements.

Whoops! Thanks for spotting this, fixed in r1202329.

Re: svn commit: r1202255 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c

[Paul Querna]

On Tue, Nov 15, 2011 at 9:17 AM, Stefan Fritsch s...@sfritsch.de wrote:
 On Tue, 15 Nov 2011, pque...@apache.org wrote:

 Author: pquerna
 Date: Tue Nov 15 15:49:19 2011
 New Revision: 1202255

 URL: http://svn.apache.org/viewvc?rev=1202255view=rev
 Log:
 disable mod_reqtimeout if not configured

 Why that? We have just changed the default to be enabled in r1199447 and
 several developers at the hackathon agreed to this change.


Didn't know it was discussed in depth at the hackathon, and there
wasn't any discussion on the list

It showed up quite quickly in my profiling of the Event MPM, because
every pull/push on the filters would cause a apr_time_now() call.

I don't really like that just by loading the module, it changes the
behavior and performance of the server so drastically.

Re: timeout queues in event mpm

[Paul Querna]

On Mon, Nov 14, 2011 at 7:47 AM, Greg Ames ames.g...@gmail.com wrote:


 On Fri, Nov 11, 2011 at 11:07 PM, Paul Querna p...@querna.org wrote:

 4) Have the single Event thread de-queue operations from all the worker
 threads.


 Since the operations include Add and Remove, are you saying we would have to
 have to wait for a context switch to the listener thread before
 apr_pollset_add() and apr_pollset_remove() or their replacements complete?
 The _add()s execute immediately on the worker threads now; I believe the
 _remove()s do too... How would you avoid adding latency to the Add
 operations?  It probably doesn't matter so much for Remove because we are
 done with the connection.

The problem became that in trunk, we had to told the lock for the
timeout queues while we were doing the pollset operation.   The
pollset already had its own internal mutex too, for its own rings.  So
we were double locking a piece of fairly high used code.  Switching to
the single-writer, single-reader queue seems to have been a win so
far.

Actually, it turns out we never call remove from the worker threads
(at least not for the main event_pollset)..

In regards to reducing latency, I'm thinking about using the
apr_pollset_wakeup API, which uses an internal pipe under the covers.
I was disappointed however that it didn't yet support using EventFD or
kqueue user events... but that should be a relatively easy set of
internal improvements inside API.

 This would remove the 4 or 5 separate timeout queues we have
 developed, and their associated mutex, and basically move all of the
 apr_pollset operations to the single main thread.

 The 4 or 5 separate queues give us a simple and cheap way to know when the
 timeouts have expired.  If we remove them, how do we maintain time order or
 otherwise do the job as cheaply as we are now?

I've kept the separate queues, you are right its much easier to
maintain, I've just removed all the locking around them.

Thanks,

Paul

Re: timeout queues in event mpm

[Paul Querna]

I've created a branch event-performance with this change and several
other changes:
 https://github.com/pquerna/httpd/compare/trunk...event-performance

I did some basic benchmarking to validate it, though if anyone has a
real test lab setup that can throw huge traffic numbers at it that
would be very helpful.

For the It works default index page, I got the following:

event mpm trunk: 15210.07 req/second
event mpm performance branch: 15775.42 req/second (~4%)
nginx 0.7.65-1ubuntu2: 12070.35

Event MPM was using a 100% default install configuration, nginx was
using Ubuntu 10.04.3 LTS default configuration, baring replacement of
the index.html to match Apache's.  I included nginx just to make sure
the we were in the same ballparks, I imagine a well tuned nginx config
can go much higher, but the same is true of Apache too :)

As an aside, In either case, using apachebench for this is kinda..
pointless, it's maxing itself out on a single core, and the machine
is... idle.  I'd be very happy if someone wrote a new benchmarking
tool and/or revamped flood. sigh.

Will try to do some more profiling and then get this into trunk in the
next day or two.

On Fri, Nov 11, 2011 at 8:07 PM, Paul Querna p...@querna.org wrote:
 hi,

 After r1201149, we now lock for lots of things, where in an ideal
 case, we shouldn't need it.

 I'm toying around with ideas on how to eliminate the need for a mutex at all.

 My current 'best' idea I think:

 1) Create a new struct, ap_pollset_operation_and_timeout_info_t, which
 contains a what pollset operation to do (Add, Remove, Flags),
 timeout_type, the timeout value, and a pointer to the conn_rec.

 2) Implement a single-reader single writer circular ring buffer of
 these structures. (Using 2x uint16_t head/end offsets stuffed into a
 single uint32_t so we can make it portability atomic using
 apr_atomic_cas32)

 3) Allocate this ring buffer per-worker.

 4) Have the single Event thread de-queue operations from all the worker 
 threads.

 This would remove the 4 or 5 separate timeout queues we have
 developed, and their associated mutex, and basically move all of the
 apr_pollset operations to the single main thread.

 Without modification to the event mpm, it would potentially cause some
 issues as the event thread isn't always waking up that often, but I
 think we can figure out a way to do this without too much pain (either
 a pipe trigger to wake up when in 'slow mode', or just lower the
 default timeout on the pollset form 500ms to like 5ms).

 Thoughts?

 Thanks,

 Paul

Re: svn commit: r1200457 - /httpd/httpd/trunk/modules/apreq/

[Paul Querna]

On Fri, Nov 11, 2011 at 7:36 AM, Stefan Fritsch s...@sfritsch.de wrote:
 On Thu, 10 Nov 2011, Joe Orton wrote:

 On Thu, Nov 10, 2011 at 06:28:00PM -0800, Jeff Trawick wrote:

 * There should have been a discussion on dev@ before promoting a
 subproject to the main distribution.
 * Two weeks before 2.4 GA (well, that's the general desire of those of
 the group that spoke up) and after the last planned beta was cut is
 not a great time to do this anyway.

 I agree with Jeff, this is going to require a lot more effort to get
 into a shippable state (across all platforms etc).  Joe

 I also think that the timing could not have been worse. Dumping 5000 lines
 of C-code and 2000 lines of headers into httpd now would delay the release
 for at least 1-2 months:

 - people need some time to review that code
 - the build is broken at least on non-unix
 - apreq would need to be adjusted to recent developments in httpd
 - duplicate code in httpd would need to be removed / changed to use apreq.
 This is especially true for the new mod_request which seems to offer a
 subset of apreq's functionality.


 I see three possible ways forward. In order of personal preference:

 1) branch 2.4.x from trunk r1200449, which was the last revision before
 apreq

 2) somehow disable apreq in the default build (e.g. require a
 --enable-broken-experimental-features configure switch) and document that
 its API/ABI is unstable and otherwise ignore it for the release

 3) Wait with the release until the issues are sorted out.

 I really don't want to delay the release further. At some point one has to
 draw the line and not include major new features. Also, a 2 month delay
 would mean that it would be impossible to include 2.4.x in the next stable
 Debian release (7/wheezy). The freeze date is scheduled for June 2012 and
 there is much work required to stabilize 2.4.x and update all the module
 packages. This would mean that it would take until the second half of
 2014(!) until 2.4.x would be available in a Debian stable release. Also, due
 to the way Ubuntu pulls packages from Debian unstable, it would take at
 least until 4/2013 until 2.4.x could be included in a Ubuntu release (though
 10/2013 seems more likely).

 I think solution 1) is preferable. There is no reason why apreq can't be
 included in 2.4.2 or 2.4.3, once its inclusion has been completed. Therefore
 I don't see any advantage in 2) and having a 2.4.x branch now would prevent
 further accidents like this one.

 In any case, if including apreq in some version of 2.4.x is planned, we
 should not release mod_request with 2.4.0.

After some reflection I agree with Stefan.

+1 to branch 2.4.x from r1200449.

(There will be a handful of non-apreq revs to merge, but should be a
15 minute thing)

2.3.15: hung worker during gracefu childl shutdown

[Paul Querna]

I noticed in www.apache.org/server-status that there was a worker with
a single connection open, all the others had been gracefully closed.

However, it'd been in that state for an hour.

GDB attached to it, backtrace here:
   https://gist.github.com/be22714685f1e370f19e

No really sure why this would happen.

Ideas?

Re: [Discuss] [VOTE] Formal deprecation of 2.0.x branch

[Paul Querna]

On Fri, Nov 11, 2011 at 12:34 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
 On 11/11/2011 1:47 PM, André Malo wrote:

 * William A. Rowe Jr. wrote:

 Stealing a plan executed by Colm for 1.3, I'd like to propose that
 we set a two week window following committers' return-from-ApacheCon
 to execute any backports of general interest and apply important
 fixes/backports to pregsub allocation and non-absolute uri parsing.

 On approval of this plan, I would offer to introduce the EOL notices
 (as we ultimately committed to 1.3), tag and roll 2.0.65 on Nov 26th
 and we would potentially approve and release 2.0 'final' this month.

 I'd prefer a security only from now on announcement / warning first, and
 keep it that way about another year or so. I don't think the users of 2.0
 are actually prepared for a statement like support is gone now, effective
 immediately.

 We can put a statement into the docs similar to 1.3 (this time
 automated...)

 So isn't it enough to say that The project will choose to publish
 further releases only for significant security fixes, or will choose
 instead to publish patches for less significant security fixes for
 12 months from the date of this final release.  From December 2012,
 no further security patches or releases should be expected for the
 2.0.x release family.?

 More useful here to tweak the message than the plan, no?


https://access.redhat.com/support/policy/updates/errata/

RHEL 4 EOLs production support February 29, 2012.

RHEL 4 includes 2.0.52.

RHEL 5 includes 2.2.x

I don't see why we would continue to support 2.0.x for longer than
Redhat's already long support cycles.

timeout queues in event mpm

[Paul Querna]

hi,

After r1201149, we now lock for lots of things, where in an ideal
case, we shouldn't need it.

I'm toying around with ideas on how to eliminate the need for a mutex at all.

My current 'best' idea I think:

1) Create a new struct, ap_pollset_operation_and_timeout_info_t, which
contains a what pollset operation to do (Add, Remove, Flags),
timeout_type, the timeout value, and a pointer to the conn_rec.

2) Implement a single-reader single writer circular ring buffer of
these structures. (Using 2x uint16_t head/end offsets stuffed into a
single uint32_t so we can make it portability atomic using
apr_atomic_cas32)

3) Allocate this ring buffer per-worker.

4) Have the single Event thread de-queue operations from all the worker threads.

This would remove the 4 or 5 separate timeout queues we have
developed, and their associated mutex, and basically move all of the
apr_pollset operations to the single main thread.

Without modification to the event mpm, it would potentially cause some
issues as the event thread isn't always waking up that often, but I
think we can figure out a way to do this without too much pain (either
a pipe trigger to wake up when in 'slow mode', or just lower the
default timeout on the pollset form 500ms to like 5ms).

Thoughts?

Thanks,

Paul

Re: svn commit: r1200040 - in /httpd/httpd/trunk: CHANGES modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h

[Paul Querna]

On Thu, Nov 10, 2011 at 12:14 AM, Rüdiger Plüm
ruediger.pl...@vodafone.com wrote:

 Author: pquerna
 Date: Wed Nov  9 23:37:37 2011
 New Revision: 1200040

 URL: http://svn.apache.org/viewvc?rev=1200040view=rev
 Log:
 Add support for RFC 5077 TLS Session tickets.  This adds two new directives:

 * SSLTicketKeyFile: To store the private information for the encryption of 
 the ticket.
 * SSLTicketKeyDefault To set the default, otherwise the first listed token is 
 used.  This
 enables key rotation across servers.

 Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
 httpd/httpd/trunk/modules/ssl/
 ssl_private.h
.
 +const char *ssl_cmd_SSLTicketKeyFile(cmd_parms *cmd, void *dcfg, const char 
 *name, const
 char *path)
 +{
 +#ifdef HAVE_TLSEXT_TICKETS
 +apr_status_t rv;
 +apr_file_t *fp;
 +apr_size_t len;
 +char buf[TLSEXT_TICKET_KEYLEN];
 +modssl_ticket_t* ticket = NULL;
 +SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
 +
 +rv = apr_file_open(fp, path, APR_READ|APR_BINARY,



 Why not using ap_server_root_relative on path first?

Fixed in r1200372.


 +
 +memcpy(keyname, ticket-key_name, 16);
 +
 +RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
 +
 +memcpy(iv, iv, EVP_MAX_IV_LENGTH);


 What is the purpose of this operation? Source and destination are the same.

Unneeded, No Purpose, I had an earlier version of the code when I used
a temp local buffer to generate the IV, but later just wrote directly
into the parameter with RAND_pseudo_bytes.  Removed in r1200374.


 Regards

 Rüdiger

Thanks again,

Paul

rethinking connection input filter API

[Paul Querna]

The input filter API function signature is the following:

apr_status_t func(
 ap_filter_t *f,
 apr_bucket_brigade *b,
 ap_input_mode_t mode,
 apr_read_type_e block,
 apr_off_t readbytes);

Problems:

1) This gives the caller of the API control over weither they can
block via the  apr_read_type_e block.

2) The caller also suggests how much data 'should' be read by passing
of readbytes, however many modules just pull in whatever they can, or
they have to put in extra logic to keep a backlog buffer.

3) Currently we have these modes:

AP_MODE_READBYTES,
AP_MODE_GETLINE,
AP_MODE_EATCRLF,
AP_MODE_SPECULATIVE,
AP_MODE_EXHAUSTIVE,
AP_MODE_INIT

This means every input filter, must implement all of these different
modes.  This significantly complicates modules like mod_ssl and
reqtimeout.  Every module to support things like speculative must
support buffering internally.

I would like to change the function signature for connection level
input filters to:

apr_status_t  func(
 ap_filter_t *f,
 apr_bucket_brigade *b);

The function always be allowed to return EAGAIN.  It would not be
responsible for polling or blocking.

This would massively simplify how most input filters work, and would
enable more creative methods of network IO inside the MPMs.

Most of the work would be in ap_rgetline_core, and figuring out how to
make it work without pushing complexity into the protocol parsers.

It would however reduce the total lines of code I believe, because we
would be centralizing all input buffering and different mode needs
into one place.

I believe we would need to add a new method to the MPMs,
ap_mpm_poll_connection() as a transitionary API.  This could be called
by ap_rgetline_core or ap_get_brigade, and in the the traditional IO
MPMs like Worker, and Prefork, select/poll on the socket until it is
available. I'm unsure about how to best fix ap_get_brigade, it is also
used within mod_proxy for client IO.

Thoughts?

Thanks,

Paul

Re: svn commit: r1200612 - in /httpd/httpd/branches/input-filter-dev: include/util_filter.h modules/debugging/mod_dumpio.c modules/filters/mod_reqtimeout.c modules/ssl/ssl_engine_io.c server/core_filt

[Paul Querna]

On Thu, Nov 10, 2011 at 3:35 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
 On 11/10/2011 4:55 PM, pque...@apache.org wrote:

 URL: http://svn.apache.org/viewvc?rev=1200612view=rev
 Log:
 Remove AP_MODE_INIT, it is a no-op, everywhere

 This was added in order to init ssl connections on protocols which
 follow a write-then-read logic like snmp or ftp.

 I should be able to create a proof of concept quickly just adding a
 mod_echo welcome message and test if it's still needed for mod_ssl.


It's not needed in mod_ssl though -- it just ignored it.

I think this got fixed when mod_ssl was changed to support RFC 2817 -
Upgrading to TLS Within HTTP/1.1.

If every module just ignores it and treats it as a no-op, why does it
matter what the protocol module wants to do?

Re: [PATCH] Support for TLS Session Tickets

[Paul Querna]

On Sun, Oct 2, 2011 at 12:20 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 On 30.09.2011 08:08, Paul Querna wrote:
 Attached is a patch
 http://people.apache.org/~pquerna/tls_session_ticket_support.patch
  to add support for setting SSL_CTX_set_tlsext_ticket_keys.

 I have two questions:

 1) What is the right ifdef to look for support of this feature?  I was
 just using ifdef SSL_CTX_set_tlsext_ticket_keys and it seemed to work
 for me..

 SSL_CTRL_SET_TLSEXT_TICKET_KEYS and #ifndef OPENSSL_NO_TLSEXT,
 respectively - I would suggest wrapping it in the same way as
 SSL_CTX_set_tlsext_servername_callback/SSL_CTX_set_tlsext_servername_arg.

 Generally speaking, I agree with Stefan that such keys shouldn't be
 stored in config files as (static) plain-text strings. RFC 5077 section
 5.5 lists some recommendations for the management of ticket protection
 keys, although it hastens to add that A full description [...] is
 beyond the scope of this document.

I've committed an updated patch that stores the key id, hmac secret,
and aes key into a file:
https://svn.apache.org/viewvc?view=revisionrevision=1200040

Feedback welcome!

Thanks,

Paul

Re: Who's at the Hackathon?

[Paul Querna]

Also around.

On Mon, Nov 7, 2011 at 1:17 PM, Roy T. Fielding field...@gbiv.com wrote:
 On Nov 7, 2011, at 9:22 AM, Sander Temme wrote:

 Folks,

 The httpd table now has:

 Jeff Trawick
 Jean-Frederic Leclere
 Stefan Fritsch
 Rainer Jung
 and myself

 Who else is at the conference?  Anybody joining tomorrow?

 I'll be around tomorrow (at the board meeting today).

 …Roy

Re: [PATCH] Support for TLS Session Tickets

[Paul Querna]

On Sat, Oct 1, 2011 at 9:48 AM, Stefan Fritsch s...@sfritsch.de wrote:
 On Fri, 30 Sep 2011, Rainer Jung wrote:

 Thanks for the info. That would definitely be a nice feature. Would it
 be safe to use a statically defined key? Only as long as the config file
 is safe?

 As I understand it, knowledge of the session ticket key allows to
 decrypt all connections that use session tickets with this key. I
 think this is true even if the tls cipher itself guarantees forward
 security (like DHE). If this is correct, the option certainly needs
 some warnings in the documentation.

 Also, I think the config file is the wrong place for the key. Just think of
 mod_info, which would display the key in the configuration. And I am also
 against generating the key from some ASCII password that likely has less
 entropy than the 48 bytes used for the key.

 What about specifying a file that contains the base64 encoded key? If
 the file does not exist, httpd could create it with a random value and
 the correct permissions. The admin would then just need to start httpd on
 one server and copy the created file to the other servers.

 Or we could just document how to create it. Under Unix, it's a one-
 liner:

 (umask 077; dd if=/dev/random bs=48 count=1|
 openssl base64  filename.key)

How about using the private key for the certificate as a signing key
as one way to get more (deterministic) data?

[PATCH] Support for TLS Session Tickets

[Paul Querna]

Hiya,

Attached is a patch
http://people.apache.org/~pquerna/tls_session_ticket_support.patch
 to add support for setting SSL_CTX_set_tlsext_ticket_keys.

I have two questions:

1) What is the right ifdef to look for support of this feature?  I was
just using ifdef SSL_CTX_set_tlsext_ticket_keys and it seemed to work
for me..

2) What is the right way to set/generate the keys -- openssl requires
that the key is 48 bytes exactly. (16 bytes for
tlsext_tick_key_nametlsext_tick_hmac_key (unused?), 16 for hmac of
session, 16 for aes key).  Right now I take the user provided key
value and use it as an HMAC key with the SHA1(Certificate) for that
vhost as the SHA256 HMAC'ed value.  I don't know what is best. I just
made this shit up, but I couldn't find any examples of
SSL_CTX_set_tlsext_ticket_keys being used, so any suggestions would be
helpful.

The other option is to require the user to provide 48 bytes of random
data (base64'ed?) rather than trying to be nice by generating it from
ascii for them.

Happy to fix/iterate or just commit to trunk,

Thanks,

Paul


tls_session_ticket_support.patch
Description: Binary data

Re: [PATCH] Support for TLS Session Tickets

[Paul Querna]

On Fri, Sep 30, 2011 at 12:38 AM, Rainer Jung rainer.j...@kippdata.de wrote:
 Hi Paul,

 On 30.09.2011 08:08, Paul Querna wrote:
 Hiya,

 Attached is a patch
 http://people.apache.org/~pquerna/tls_session_ticket_support.patch
  to add support for setting SSL_CTX_set_tlsext_ticket_keys.

 Unfortunately I don't have answers to your questions, but I'm a bit
 curious about the patch. As far as I understand we already support RFC
 5077 (even with 2.2.x). So am I right, that the patch is about improving
 key handling?

 The Changelog for OpenSSL 0.9.8f says:

 *) Add RFC4507 support to OpenSSL. This includes the corrections in
     RFC4507bis. The encrypted ticket format is an encrypted encoded
     SSL_SESSION structure, that way new session features are automatically
     supported.

 ...

     The SSL_CTX structure automatically generates keys for ticket
     protection in servers so again support should be possible
     with no application modification.

 So do we actually need to worry about the keys?

If you don't set anything, OpenSSL randomly generates a key
per-SSL_CTX.  This is useful in a single server environment, as it
generally just works, and should be less load than using the normal
ssl session cache.

The reason you would want to set the keys is so that you can have
multiple Apache instances terminating SSL.  If they all use the same
certificate and ticket key, then you can essentially share SSL
Sessions between nodes without using a cache like memcached, by
relying upon the client to share state with the other SSL terminator.

 Then for 0.9.8g there is the following change:

  *) Add TLS session ticket callback. This allows an application to set
     TLS ticket cipher and HMAC keys rather than relying on hardcoded fixed
     values. This is useful for key rollover for example where several key
     sets may exist with different names.

This actually more fully exposes the feature.   Built into RFC 5077 is
the ability to have multiple key names.  So, you could have multiple
private AES keys active at once, all with different names.

The patch as written does not support this use case.  I thought about
making a apr_table_t for this purpose, but it looked far more
complicated.   The callback is given an HMAC and EVP Digest objects
and is responsible for initializing them based on the server key.  I'm
open to doing it if people are interested in this feature, but for a
v0 it seemed like supporting setting the keys at all was a good start,
over building a fairly complicated callback/table of keys.

 There was some discussion about improving session ticket support in 2009:

 http://www.mail-archive.com/dev@httpd.apache.org/msg46095.html

 The thread contains some interesting remark by Stephen concerning the
 keys. The proposed code IMHO was never applied (nor was there consensus).

 Finally there is a Bugzilla about session tickets not respecting the
 defined session timeout:

 https://issues.apache.org/bugzilla/show_bug.cgi?id=50869


AFAIK there is no way of 'fixing' this without digging into the
internals of OpenSSL, they don't expose an API for controlling the
timeout settings for the Session tickets.  You can set
SSL_CTX_set_timeout, which effects both session tickets normal
sessions.

www.apache.org upgraded to 2.3.15-dev-r116760

[Paul Querna]

Infra has upgraded eos, aka the main webserver for *.apache.org to
2.3.15-dev-r116760

We started with going to 2.3.14-beta, but it was missing all the
range-header changes, so we decided to pull up to trunk at the current
time, which is r116760.

We ran into a few small issues in upgrading from 2.3.8:

  * mod_asis was demoted from 'most', we changed --enable-mods-shared
from 'most' to 'all'. [1]

  * mod_imagemap was also removed from 'most', but we just removed it
from our configuration.

  * We had a bad ServerName value of bugs.*.apache.org, this caused
an error on startup, but was easily fixed by changing it to a
ServerAlias.

  * We had some painful issues dealing with --with-included-apr.
Basically we always ended up linking to the system APR installed in
/usr/local/lib.  We 'fixed' this for now by explicitly setting
LD_LIBRARY_PATH=/usr/local/apache2-install/www.apache.org/current/lib/
in our init scripts to , and when building httpd we temporarily 'hid'
the system APR by running `gzip /usr/local/lib/libapr*`, so that the
linker wouldn't pick it up. (hat trick to danielsh for the gzip idea).
This issue caused BDB 4.2 to be used by APR-Util, which caused
mod_mbox to not work, since it was using BDB 4.8.  We are currently
looking at ways to fix our system APR, but it would be nice if
--with-included-apr consistently worked.

Bonus points for adding the connection count summary table into mod_status:
  http://www.apache.org/server-status

If you notice any issues, please let infrastructure@ know,

Thanks!

[1] - config.nice: https://gist.github.com/4b95f959282820bd6753

Re: www.apache.org upgraded to 2.3.15-dev-r116760

[Paul Querna]

Oops, that would actually be r1167603, dropped off the last character somewhere.

On Sun, Sep 11, 2011 at 12:10 PM, Paul Querna p...@querna.org wrote:
 Infra has upgraded eos, aka the main webserver for *.apache.org to
 2.3.15-dev-r116760

 We started with going to 2.3.14-beta, but it was missing all the
 range-header changes, so we decided to pull up to trunk at the current
 time, which is r116760.

 We ran into a few small issues in upgrading from 2.3.8:

  * mod_asis was demoted from 'most', we changed --enable-mods-shared
 from 'most' to 'all'. [1]

  * mod_imagemap was also removed from 'most', but we just removed it
 from our configuration.

  * We had a bad ServerName value of bugs.*.apache.org, this caused
 an error on startup, but was easily fixed by changing it to a
 ServerAlias.

  * We had some painful issues dealing with --with-included-apr.
 Basically we always ended up linking to the system APR installed in
 /usr/local/lib.  We 'fixed' this for now by explicitly setting
 LD_LIBRARY_PATH=/usr/local/apache2-install/www.apache.org/current/lib/
 in our init scripts to , and when building httpd we temporarily 'hid'
 the system APR by running `gzip /usr/local/lib/libapr*`, so that the
 linker wouldn't pick it up. (hat trick to danielsh for the gzip idea).
    This issue caused BDB 4.2 to be used by APR-Util, which caused
 mod_mbox to not work, since it was using BDB 4.8.  We are currently
 looking at ways to fix our system APR, but it would be nice if
 --with-included-apr consistently worked.

 Bonus points for adding the connection count summary table into mod_status:
  http://www.apache.org/server-status

 If you notice any issues, please let infrastructure@ know,

 Thanks!

 [1] - config.nice: https://gist.github.com/4b95f959282820bd6753

Re: 3.0, the 2011 thread.

[Paul Querna]

2011/6/18 Igor Galić i.ga...@brainsware.org:


 - Original Message -
 On Friday 17 June 2011, Graham Leggett wrote:
  We used openssl to make our non blocking event driven stuff work,
  and it works really well (once you've properly handled
  SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE). There is no reason
  I can see that would stop us using openssl to be async in httpd,
  we just need to refactor the mod_ssl code to actually do it.

 Someone (Paul?) once told me that openssl is not very good when it
 comes to async access to the session cache (which could need network
 io if using memcached), CRLs (which I could imagine to reside in
 LDAP)
 and similar things. But this would have to be evaluated.

  The tricky part with event driven code is the really bad support
  for   event driven file access. We used libev as our core event
  loop, which does a significant amount of work to make files and
  sockets work the same way in the event loop as best it can in a
  portable way. Don't know of any other event loop that does this.
  It's difficult trying to do the event driven thing if you
  intersperse event driven socket handling with blocking file
  handling, you end up with many requests blocked by an unrelated
  system call.

 Yes, I guess we would need a pool of lightweight worker threads that
 does the file io (especially sendfile). Those threads would probably
 get by with very small stack sizes and use little resources. If the
 event library we choose already has this built in, we can of course
 use that, too.

 This kind of reminds me of the architecture of Apache Traffic Server
 see http://www.slideshare.net/zwoop/rit-2011-ats


Yes, ATS is the right model I think, but I don't think the... C++isms
and general bagage that comes along with it are ideal for httpd
though?

Re: 3.0, the 2011 thread.

[Paul Querna]

On Wed, Jun 15, 2011 at 4:33 PM, Graham Leggett minf...@sharp.fm wrote:
 On 16 Jun 2011, at 12:01 AM, Paul Querna wrote:

 I think we have all joked on and off about 3.0 for... well about 8 years
 now.

 I think we are nearing the point we might actually need to be serious
 about it.

 The web is changed.

 SPDY is coming down the pipe pretty quickly.

 WebSockets might actually be standardized this year.

 Two protocols which HTTPD is unable to be good at. Ever.

 The problem is our process model, and our module APIs.

 I am not convinced.

 Over the last three years, I have developed a low level stream serving
 system that we use to disseminate diagnostic data across datacentres, and
 one of the basic design decisions was that  it was to be lock free and event
 driven, because above all it needed to be fast. The event driven stuff was
 done properly, based on religious application of the following rule:

 Thou shalt not attempt any single read or write without the event loop
 giving you permission to do that single read or write first. Not a single
 attempt, ever.

 From that effort I've learned the following:

 - Existing APIs in unix and windows really really suck at non blocking
 behaviour. Standard APR file handling couldn't do it, so we couldn't use it
 properly. DNS libraries are really terrible at it. The vast majority of
 async DNS libraries are just hidden threads which wrap attempts to make
 blocking calls, which in turn means unknown resource limits are hit when you
 least expect it. Database and LDAP calls are blocking. What this means
 practically is that you can't link to most software out there.


Yes.

Don't use the existing APIs.

Use libuv for IO.

Use c-ares for DNS.

Don't use LDAP and Databases in the Event Loop;  Not all content
generation needs to be in the main event loop, but lots of content
generation and handling of clients should be.

 - You cannot block, ever. Think you can cheat and just make a cheeky attempt
 to load that file quickly while nobody is looking? Your hard disk spins
 down, your network drive is slow for whatever reason, and your entire server
 stops dead in its tracks. We see this choppy behaviour in poorly written
 user interface code, we see the same choppy behaviour in cheating event
 driven webservers.

Node.js doesn't cheat.  It works fine.  Its not that hard to  not
do file IO in the event loop thread.

 - You have zero room for error. Not a single mistake can be tolerated. One
 foot wrong, the event loop spins. Step one foot wrong the other way, and
 your task you were doing evaporates. Finding these problems is painful, and
 your server is unstable until you do.

This sounds like an implementation problem.  This is not a problem in Node.js.

 - You have to handle every single possible error condition. Every single
 one. Miss one? You suddenly drop out of an event handler, and your event
 loop spins, or the request becomes abandoned. You have no room for error at
 all.

I'm not suggesting the whole thing is trivial, but how is this worse
than our current situation?

 We have made our event driven code work because it does a number of very
 simple and small things, and it's designed to do these simple and small
 things well, and we want it to be as compact and fast as humanly possible,
 given that datacentre footprint is our primary constraint.

 Our system is like a sportscar, it's fast, but it breaks down if we break
 the rules. But for us, we are prepared to abide by the rules to achieve the
 speed we need.

 Let's contrast this with a web server.

 Webservers are traditionally fluid beasts, that have been and continue to be
 moulded and shaped that way through many many ever changing requirements
 from webmasters. They have been made modular and extensible, and those
 modules and extensions are written by people with different programming
 ability, to different levels of tolerances, within very different budget
 constraints.

 Simply put, webservers need to tolerate error. They need to be built like
 tractors.

 Unreliable code? We have to work despite that. Unhandled error conditions?
 We have to work despite that. Code that was written in a hurry on a budget?
 We have to work despite that.

You are confusing the 'core' network IO model with fault isolation.
The Worker MPM has actually been quite good on most platforms for the
last decade.   There is little reason to use prefork anymore.

Should we run PHP inside the core event loop?  Hell no.

We can build reasonable fault isolation for modules that wish to have
it, probably even do it by default, and if a module 'opts' in, or
maybe there are different APIs, it gets to run in the Event Loop.

 Are we going to be sexy? Of course not. But while the sportscar is broken
 down at the side of the road, the tractor just keeps going.

 Why does our incredibly unsexy architecture help webmasters? Because prefork
 is bulletproof. Leak, crash, explode, hang, the parent will clean up after
 us. Whatever

Re: 3.0, the 2011 thread.

[Paul Querna]

2011/6/15 Colm MacCárthaigh c...@allcosts.net:
 On Wed, Jun 15, 2011 at 3:01 PM, Paul Querna p...@querna.org wrote:
 I think we have all joked on and off about 3.0 for... well about 8 years now.

 At least!

 I think there are exciting things happening in C however.

 I love C, but unless we can come up with something radical, it's hard
 to see a way out of the prison it creates. That realisation led me to
 hacking mostly on functional-oriented servers. I'll try to explain why
 - in case any of those thoughts are useful here too :)

 I like the things you've pointed out, but they seem relatively
 cosmetic. Things like the parser, async, event and portability
 frameworks are really cool - but hardly fundamental. Anyone could use
 those, in any language - it's not a real leap in the field. Similarly,
 SPDY, websockets, COMET and so on are ultra-cool - but are still
 potential bolt-ons to almost any kind of webserver. It sucks that we
 don't do them well, but doing them better won't fundamentally change
 the market or the pressures on adoption.

 Today webservers are almost entirely network I/O bound - disk seek and
 CPU speeds are pretty great these days, way faster than is really
 neccessary. In a properly architected set-up, end-user delay is really
 about the limitations of TCP. You can multiplex and use keepalives as
 much as you want, you'll eventually realise that the size of the world
 and speed of light mean that this inevitably ends up being slow
 without a lot of distributed endpoints.

 But we have some cool secret sauce to help fix that. I think the best
 architectural thing about Apache is buckets and brigades. Using a list
 structure to represent portions of differently-generated content like
 that is great. Imagine how much better wordpress would run if PHP
 represented the php scripts as a some dynamic buckets intermingled
 with some static file io buckets (and even repeated when in loops).
 There'd be a lot less data to copy around.

 Now imagine a backend that could identify the dynamic buckets and, by
 forbidding side effects, parallellise work on them - a bucket as a
 message in message-passing system of co-routines, for example. Imagine
 that in turn feeding into a set of co-routine filters. That's
 fundamentally different - it parallelises content generation, but it's
 really really hard to do in C.

 Then next, imagine a backend that could identify the static buckets
 and re-order them so that they come first - it could understand things
 like XML and Javascript and intelligently front-load your transfer so
 that the content we have ready goes first, while the dynamic stuff is
 being built. It's a real layer-8-aware scheduler and content
 re-compiler. Again it's really really hard to do in C - but imagine
 the benefits of a server layer that really understood how to model and
 re-order content.

 These are the kinds of transform that make a webservers job as optimal
 as it can be. Network data is the most expensive part of any modern
 web application, in terms of both time and money, so the ecosystem
 faces huge economic pressure to make these as optimal as possible over
 time. Things like SPDY are just the first generation.

 It'd be cool if Apache 3.0 could do those things - we have some great
 building blocks and experience - but it feels like a language with
 support for first-order functions and co-routines would be better at
 it.

 Again, I'm just thinking out loud :)

I think its an interesting idea, focusing on a content aware server
architecture;  An example of this is SPDY's ability to push content
for a client -- For example, a client requests /index.html, you can
push /css/main.css to them without waiting for them to request it.

I think as far as the implementation language, you seem to be asking for Go?

Which I really really like, but it seems hard to make extensions/module APIs.

Of course, the other option is to just write it in Node.js  I mean
most of the web erver is not about the lower bits, its about
configuration and content generation.

3.0, the 2011 thread.

[Paul Querna]

I think we have all joked on and off about 3.0 for... well about 8 years now.

I think we are nearing the point we might actually need to be serious about it.

The web is changed.

SPDY is coming down the pipe pretty quickly.

WebSockets might actually be standardized this year.

Two protocols which HTTPD is unable to be good at. Ever.

The problem is our process model, and our module APIs.

The Event MPM was a valiant effort in some ways, but mod_ssl and other
filters will always block its progress, and with protocols like SPDY,
falling back to Worker MPM behaviors is pointless.

I think there are exciting things happening in C however.

4 projects that maybe could form the baseline for something new.

pocore: For base OS portability and memory pooling system.
  http://code.google.com/p/pocore/
libuv: Portable, fast, Network IO. (IOCP programming model, brought to Unix)
  https://github.com/joyent/libuv
http-parser: HTTP really broken out to simple callbacks.
  https://github.com/ry/http-parser
selene: SSL, redone to better support Async IO.
  https://github.com/pquerna/selene

All of these are young.  Most are incomplete.

But they could be the tools to build a real 3.0 upon.

If we don't, I'm sure others in the web server market will continue to
gain market share.

But I think we could make do it better.  We have the experience, we
know the value of a modules ecosystem, we build stable, quality
software.  We just need to step up to how the internet is changing.

Thoughts?

Thanks,

Paul

Re: 3.0, the 2011 thread.

[Paul Querna]

On Wed, Jun 15, 2011 at 3:26 PM, Akins, Brian brian.ak...@turner.com wrote:
 On 6/15/11 6:01 PM, Paul Querna p...@querna.org wrote:

 pocore: For base OS portability and memory pooling system.
   http://code.google.com/p/pocore/

 How does this compare to APR?

It's like an APR version 3.0.

It has a faster pools system, with the ability to free() items, and it
drops all of the apr-utilism things like databases, ldap, etc.

Re: svn commit: r1133582 - in /httpd/httpd/trunk: CHANGES docs/manual/filter.xml docs/manual/mod/mod_data.xml docs/manual/mod/mod_data.xml.meta docs/manual/new_features_2_4.xml modules/filters/config.

[Paul Querna]

On Thu, Jun 9, 2011 at 12:13 AM,  minf...@apache.org wrote:
 Author: minfrin
 Date: Wed Jun  8 22:13:21 2011
 New Revision: 1133582

 URL: http://svn.apache.org/viewvc?rev=1133582view=rev
 Log:
 mod_data: Introduce a filter to support RFC2397 data URLs.

Why is this in the core?

The example in the documentation doesn't make sense, this data encoded
this way is inline, not the whole response.

I don't get why this is a filter in httpd core, its a feature of an
app server when its generate its HTML?

 Added:
    httpd/httpd/trunk/docs/manual/mod/mod_data.xml
    httpd/httpd/trunk/docs/manual/mod/mod_data.xml.meta
    httpd/httpd/trunk/modules/filters/mod_data.c
 Modified:
    httpd/httpd/trunk/CHANGES
    httpd/httpd/trunk/docs/manual/filter.xml
    httpd/httpd/trunk/docs/manual/new_features_2_4.xml
    httpd/httpd/trunk/modules/filters/config.m4

 Modified: httpd/httpd/trunk/CHANGES
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1133582r1=1133581r2=1133582view=diff
 ==
 --- httpd/httpd/trunk/CHANGES [utf-8] (original)
 +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Jun  8 22:13:21 2011
 @@ -2,6 +2,9 @@

  Changes with Apache 2.3.13

 +  *) mod_data: Introduce a filter to support RFC2397 data URLs. [Graham
 +     Leggett]
 +
   *) mod_userdir/mod_alias/mod_vhost_alias: Correctly set DOCUMENT_ROOT,
      CONTEXT_DOCUMENT_ROOT, CONTEXT_PREFIX. PR 26052. PR 46198.
      [Stefan Fritsch]

 Modified: httpd/httpd/trunk/docs/manual/filter.xml
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/filter.xml?rev=1133582r1=1133581r2=1133582view=diff
 ==
 --- httpd/httpd/trunk/docs/manual/filter.xml (original)
 +++ httpd/httpd/trunk/docs/manual/filter.xml Wed Jun  8 22:13:21 2011
 @@ -38,6 +38,13 @@
         modulemod_include/module
         modulemod_charset_lite/module
         modulemod_reflector/module
 +        modulemod_buffer/module
 +        modulemod_data/module
 +        modulemod_ratelimit/module
 +        modulemod_reqtimeout/module
 +        modulemod_request/module
 +        modulemod_sed/module
 +        modulemod_substitute/module
       /modulelist
       directivelist
         directive module=mod_filterFilterChain/directive

 Added: httpd/httpd/trunk/docs/manual/mod/mod_data.xml
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_data.xml?rev=1133582view=auto
 ==
 --- httpd/httpd/trunk/docs/manual/mod/mod_data.xml (added)
 +++ httpd/httpd/trunk/docs/manual/mod/mod_data.xml Wed Jun  8 22:13:21 2011
 @@ -0,0 +1,69 @@
 +?xml version=1.0?
 +!DOCTYPE modulesynopsis SYSTEM ../style/modulesynopsis.dtd
 +?xml-stylesheet type=text/xsl href=../style/manual.en.xsl?
 +!-- $LastChangedRevision: 966890 $ --
 +
 +!--
 + Licensed to the Apache Software Foundation (ASF) under one or more
 + contributor license agreements.  See the NOTICE file distributed with
 + this work for additional information regarding copyright ownership.
 + The ASF licenses this file to You under the Apache License, Version 2.0
 + (the License); you may not use this file except in compliance with
 + the License.  You may obtain a copy of the License at
 +
 +     http://www.apache.org/licenses/LICENSE-2.0
 +
 + Unless required by applicable law or agreed to in writing, software
 + distributed under the License is distributed on an AS IS BASIS,
 + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + See the License for the specific language governing permissions and
 + limitations under the License.
 +--
 +
 +modulesynopsis metafile=mod_data.xml.meta
 +
 +namemod_data/name
 +descriptionConvert response body into an RFC2397 data URL/description
 +statusExtension/status
 +sourcefilemod_data.c/sourcefile
 +identifierdata_module/identifier
 +compatibilityAvailable in Apache 2.3 and later/compatibility
 +
 +summary
 +    pThis module provides the ability to convert a response into
 +    an a href=http://tools.ietf.org/html/rfc2397;RFC2397 data URL/a.
 +    /p
 +
 +    pData URLs can be embedded inline within web pages using something
 +    like the modulemod_include/module module, to remove the need for
 +    clients to make separate connections to fetch what may potentially be
 +    many small images. Data URLs may also be included into pages generated
 +    by scripting languages such as PHP./p
 +
 +    exampletitleAn example of a data URL/title
 +        data:image/gif;base64,R0lGODdhMAAwAPAAAP///ywAMAAwbr /
 +        AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzbr /
 +        ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpbr /
 +        a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlbr /
 +        ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uisbr /
 +        

Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h

[Paul Querna]

On Sun, Feb 13, 2011 at 5:03 AM, Graham Leggett minf...@sharp.fm wrote:
 On 13 Feb 2011, at 9:59 AM, Roy T. Fielding wrote:

 URL: http://svn.apache.org/viewvc?rev=1070179view=rev
 Log:
 mod_cache: When a request other than GET or HEAD arrives, we must
 invalidate existing cache entities as per RFC2616 13.10. PR 15868.

 Cache entries should not be invalidated unless the response comes
 back as a success (2xx).  Likewise, it only applies to methods with
 known write effects (not including TRACE, OPTIONS, PROPFIND, etc.).

 This has already been updated in httpbis p6.

 Hmmm...

 So is it right to say that POST, PUT and DELETE should invalidate, while all
 others would be left alone?

 Or do we need some kind of mechanism for modules that respond to new methods
 to declare those methods as needing to be invalidated or not?

 Should the cache try and cache any of the other methods, or is cacheability
 limited to GET only?


Additionally, this should be a configurable behavior.

Lets say you run a popular website that depends on mod_cache to
protect backend systems from complete overload.

All you need to do now as an attacker is POST / DELETE to / or another
important URL every 200ms, and the cache becomes invalidated, causing
a flood of requests to backends that might not be able to support it.

Thoughts?

Thanks,

Paul

Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h

[Paul Querna]

On Sun, Feb 13, 2011 at 4:00 PM, Graham Leggett minf...@sharp.fm wrote:
 On 14 Feb 2011, at 1:56 AM, Paul Querna wrote:

 Additionally, this should be a configurable behavior.

 Lets say you run a popular website that depends on mod_cache to
 protect backend systems from complete overload.

 All you need to do now as an attacker is POST / DELETE to / or another
 important URL every 200ms, and the cache becomes invalidated, causing
 a flood of requests to backends that might not be able to support it.

 Thoughts?

 How is this different from Cache-Control: no-cache in the request?

It does a single request to the backend, but doesn't _invalidate_ the
existing cache, which would cause a flood of other, non-attacker
clients to come in.

Re: mod_cache: disk layout for vary support

[Paul Querna]

On Sun, Oct 10, 2010 at 8:56 AM, Graham Leggett minf...@sharp.fm wrote:
 Hi all,

 One of the things that needs to be fixed with mod_cache is the support for
 caching varying responses. In the current cache, we store it as below, as an
 additional directory tree below the original URL's directory tree. This
 wastes lots of inodes, and is very expensive to write.

 /tmp/cacheroot/
 /tmp/cacheroot//1uq
 /tmp/cacheroot//1uq/w...@d
 /tmp/cacheroot//1uq/w...@d/Fok
 /tmp/cacheroot//1uq/w...@d/Fok/HRU
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5/im1
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5/im1/RSz
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5/im1/RSz/fCK
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5/im1/RSz/fCK/YHquMmA.data
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/thJ/bK5/im1/RSz/fCK/YHquMmA.header

 What I have in mind is to move the varied content into the main tree, like
 this:

 /tmp/cacheroot/
 /tmp/cacheroot//1uq
 /tmp/cacheroot//1uq/w...@d
 /tmp/cacheroot//1uq/w...@d/Fok
 /tmp/cacheroot//1uq/w...@d/Fok/HRU
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62
 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header
 /tmp/cacheroot//thJ
 /tmp/cacheroot//thJ/bK5
 /tmp/cacheroot//thJ/bK5/im1
 /tmp/cacheroot//thJ/bK5/im1/RSz
 /tmp/cacheroot//thJ/bK5/im1/RSz/fCK
 /tmp/cacheroot//thJ/bK5/im1/RSz/fCK/YHquMmA.data
 /tmp/cacheroot//thJ/bK5/im1/RSz/fCK/YHquMmA.header

 We reuse the same directory structure in the process, and keep the original
 QSJf2JA.header file indicating that the URL is a varied URL.

The problem with the second layout is that it makes it near impossible
to clear out all variants of a URL easily.

I think there are far more general issues with waste of inodes on the
cache disk format, than anything to do with varres.

I would rather change the defaults to use only two letters and two
levels deep for the cache directories, and probally restrict the
character set even further to just [a-zA-Z].

I think a case should be made for not using sub-directories inside the
.varies folder. Instead just flatten it out and put all the variants
inside a flat directory, rather than distributing them over the cache
again.

Thanks,

Paul

Re: Remove Limit and LimitExcept ?

[Paul Querna]

On Sun, Sep 19, 2010 at 8:40 AM, Ruediger Pluem rpl...@apache.org wrote:


 On 09/19/2010 12:45 AM, Stefan Fritsch wrote:
 This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927

 On Saturday 18 September 2010, bugzi...@apache.org wrote:
 --- Comment #3 from Nick Kew n...@webthing.com 2010-09-18
 06:38:34 EDT ---

 No, the current documentation is correct. The semantics of
 Limit/LimitExcept is just insane. We should relly get rid if it
 in 2.4 and improve the docs for 2.2. Maybe the unprotected
 should be big, red, and blinking ;-)
 Agreed.  We can even document it as superseded by
 If $request-method ...
 having of course checked the expression parser, which probably
 needs updating to support things like
    ... in GET,HEAD,OPTIONS,TRACE
 without some nasty great OR expression.

 What do other people think about removing Limit and LimitExcept
 and adding mod_allowmethods from the sandbox to easily forbid some
 methods? Or would this create too much trouble when upgrading
 configurations?


 BTW, we could also add an authz provider to allow things like

 Require method GET,HEAD,...

 Though this would be slower than mod_allowmethods because authz
 providers have to parse the require line on every request.

 Hm. I don't like it to be removed until be have an agreed alternative
 in trunk. And the question is whether we should still do this after
 we had a first beta release.

This is the module that infrastructure uses (and I wrote) to replace
use of limits on *.apache.org:
https://svn.apache.org/repos/infra/infrastructure/trunk/projects/mod_allowmethods/mod_allowmethods.c

It was written after the last attack on our servers in which the
attackers uploaded CGI scripts;  We have some specific use cases where
we want to allow CGI in some places, but all of them have very limited
methods they should accept.  Trying to configure Limit for our use
case and diverse set of vhosts would of meant duplicating the config
in hundreds of places.  I don't think the module is really great as an
alternative, but it is one path to consider, and is working for at
least one use case :)

Re: mod_cache: store_body() bites off more than it can chew

[Paul Querna]

On Thu, Sep 2, 2010 at 10:16 AM, Graham Leggett minf...@sharp.fm wrote:
 Hi all,

 An issue with mod_cache I would like to address this weekend is the
 definition of the store_body() function in the cache implementation
 provider:

    apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
 apr_bucket_brigade *b);

 Right now, mod_cache expects a cache implementation to swallow the entire
 bucket brigade b before returning to mod_cache.

 This is fine until the bucket brigade b contains something really large,
 such as a single file bucket pointing at a 4GB DVD image (such a scenario
 occurs when files on a slow disk are cached on a fast SSD disk). At this
 point, mod_cache expects the cache implementation to swallow the entire
 brigade in one go, and this can take a significant amount of time, certainly
 enough time for the client to get bored and time out should the file be
 large and the original disk slow.

Isn't this problem an artifact of how all bucket brigades work, and is
present in all output filter chains?

An output filter might be called multiple times, but a single bucket
can still contain a 4gb chunk easily.

It seems to me it would be better to think about this holistically
down the entire output filter chain, rather than building in special
case support for this inside mod_cache's internal methods?

 What I propose is a change to the function that looks like this:

    apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
 apr_bucket_brigade *in, apr_bucket_brigade *out);

 Instead of one brigade b being passed in, we pass two brigades in, one
 labelled in, the other labelled out.

 The brigade previously marked b becomes in, and the cache implementation
 is free to consume as much of the in brigade as it sees fit, and as the
 in brigade is consumed, the consumed buckets are moved to the out
 brigade.

 If store_body() returns with an empty in brigade, mod_cache writes the
 out brigade to the output filter stack and we are done as is the case now.

 Should however the cache implementation want to take a breath, it returns to
 mod_cache with unconsumed bucket(s) still remaining in the in brigade.
 mod_cache in turn sends the already-processed buckets in the out brigade
 down the filter stack to the client, and then loops round, calling the
 store_body() function again until the in brigade is empty.

 In this way, the cache implementation has the option to swallow data in as
 many smaller chunks as it sees fit, and in turn the client gets fed data
 often enough to not get bored and time out if the file is very large.

 Regards,
 Graham
 --

Re: HTTPD upgraded on eos - 2.3.8

[Paul Querna]

On Tue, Aug 24, 2010 at 10:59 PM, Ruediger Pluem rpl...@apache.org wrote:


 On 08/25/2010 02:10 AM, Tony Stevenson wrote:
 On Wed, Aug 25, 2010 at 01:04:01AM +0100, Tony Stevenson wrote:

 Had to comment out an output filter line in the main httpd.conf (line 117)

 More specifically had to disable deflate -  AddOutputFilterByType DEFLATE 
 text/html text/plain text/xml application/xml application/xml+rss text/css 
 application/x-javascript
 The deflate module is loaded, and seemingly not causing any outwardly 
 obvious issues

 Thoughts?

 AddOutputFilterByType moved from core to mod_filter (see
 http://svn.apache.org/viewvc?rev=966869view=rev)

 So I guess mod_filter is not loaded. If it is the line should work again.


Grump old man mode, this seems moderately disturbing.

Previously it was single hash table look up on the content-type, which
contained a list of all filters to apply.

It has been replaced with iterating all possible filters and executing
an the expression parser for each possible filter.

Is anyone else surprised at this change?  I did a quick search on
dev@, and I couldn't find any previous discussion of this change

Re: [PRERELEASE TARBALLS] httpd-2.3.8

[Paul Querna]

On Tue, Aug 24, 2010 at 3:04 PM, Guenter Knauf fua...@apache.org wrote:
 Hi all,
 Am 24.08.2010 18:42, schrieb Jim Jagielski:

 The pre-release test tarballs for httpd-2.3.8 (alpha) are
 available for download, test and fun:

        http://httpd.apache.org/dev/dist/

 Will call for a release vote in a coupla days...

 I know that this topic was already up here, but nevertheless I think we
 should re-think about including PCRE again.
 Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and
 I see no benefit in dropping it from our dependencies deliveries other than
 making tarballs smaller, and that is nowadays certainly not an issue
 anymore.
 We want Apache to build form source on at many platforms as possible - sure
 the main target is Linux / Unix, but we have a couple of other platforms
 where PCRE is not installed by default, that are at least Win32, NetWare,
 most likely OS/2, and probably a couple of others too.
 I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went
 fine only because I have an (self) adapted makefile (from previous times
 when we shipped PCRE), the Win32 stuff is horrible: there comes some
 suggestion up that I should build PCRE with CMake with xxx option; 1st I
 have to download CMake and depend on another build tool (ok, not that big
 issue), but whats even more worse is that the CMake build failed for me, and
 thats really bad - you cant just go and build httpd as you do on Linux, no!
 Your build process is always interupted, and probably as in my case finally
 broken at all.
 Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our
 own makefile, and the build goes through in one go without need for other
 tools like CMake - just the compiler and probably a platform PDK are enough
 (and thats how it shoud be).
 Therefore I want to start a vote here again where we vote for including PCRE
 again with the dependencies - just as we (now) do with APR/APU;
 and everyone who votes against should give some good reasons what speaks
 against -- the fact that every Linux comes with PCRE is certainly no good
 reason - it only leads finally to the fact that we might end up with 50
 builds of httpd 2.after-2.x with different PCE versions which makes then
 nice bug hunting, and we cant even tell someone who faces a prob to 'use our
 shipping PCRE which is known to be good'.

 Here we go:

 [ ] YES - include recent PCRE again with dependencies (means we
    create a PCRE repo in svn, check in a recent version, and add
    platform-dependent makefiles which are fully integrated into
    main build process).

 [ ] NO - dont include PCRE (as currently) because of reason: ...

 [X] NO:

There are 3-5 PCRE releases per year[1], and as a project our history
of staying up to date (including security and just bug fixes) was
generally pretty bad.  Bundling our own PCRE is a security risk best
managed by operating system vendors who take care of backporting
patches to 4 year old versions, as an upstream I see very little value
in maintaining PCRE in tree, and plenty of risks.

It seems to enable porting on other platforms, we could make a shell
script that downloaded PCRE and any other dependencies like it
(OpenSSL?), but I don't believe this has a place in the main
distribution tarball.

Thanks,

Paul
[1] - http://www.pcre.org/news.txt

Re: trunk ping for http proxy

[Paul Querna]

On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski j...@jagunet.com wrote:

 On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote:

 This basicly sums up the downsides of this approach I see as well.

 IMHO to avoid a spec violation we can only add the Expect header to
 requests with request bodies. OTOH these requests hurt most when they
 fail as we cannot sent the request body for a second time, because
 we do not have it any longer available in most situations and requests
 with request bodies are usually not idempotent.

 On the second issue we only need to take care that we do not add something
 already there and remove something that client expects to see.

 One last thing I see is that this only works if the backend is HTTP/1.1:

 8.2.3

 - If the proxy knows that the version of the next-hop server is HTTP/1.0 or 
 lower
  , it MUST NOT forward the request and it MUST respond with a 417 
 (Expectation Failed)
  status.

 Yes, the code itself is aware of the limitations of 100-Continue,
 including version and req body considerations... It's not ideal,
 but it's better than the OPTIONS method which I played around
 with earlier...

 Still I think it's useful to add it in, have it disabled by
 default, and see how far we can take it...

I think the only options really are a status URL, with a regex match,
so you can test if the backend has an expected content, and having the
backends advertise/notify the proxy that they are alive.

AFAIK, we don't do a good enough job on the first approach, and this
is how many commercial load balancers test if a destination is alive.

The second approach is done with the heartbeat code, though it would
be nice to support it without requiring multicast.  (ie backends ping
the frontend at a specific URL)

Both of these are painful to handle inside a request cycle -- ideally
they would be handled outside blocking any single request from
finishing or processing.  Doing this week inside the request cycle
just seems out of place.

I guess mod_proxy_x could fork() off a child like mod_cgid and then
check backend statuses asynchronously to requests, but thats a
mountain of work :)

Re: trunk ping for http proxy

[Paul Querna]

On Mon, Aug 16, 2010 at 2:28 PM, Andrew Oliver acoli...@gmail.com wrote:
 Note that it is an option, not a default setting.  The problem with
 the heartbeat bit which Red Hat/JBoss use is the unstandardized
 proprietary protocol required (http://jboss.org/mod_cluster) with
 separate logic to manage it.

No, in 2.3/trunk, there is a bundled module to provide this in httpd:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_heartbeat.c

 The problem with the status url is that it doesn't accomplish the same
 thing nor is it that very manageable with multiple contexts (i.e
 http://server1:8080/foo http://server1:8081/bar ...).  You'd have to
 make a separate request each time.

 Purpose:

 C = Browser
 P = middle apache server
 W = destination web server (probably tomcat)

 C--P---W

 C asks for http://myserver/someDatabaseBackedThing
 P matches and forwards this request to W with the expect continue and
 specified 5 sec expect-continue timeout.  A separate overall proxy
 timeout of 1 minute is set.
 W returns a continue but then begins to process the request
 (CGI/JavaServlet/PHP whatever to the database)
 W spends less than a minute and the request is successful

 C asks for http://myserver/someDatabaseBackedThing
 P matches and forwards this request to W with the expect continue and
 specified 5 sec expect-continue timeout.  A separate overall proxy
 timeout of 1 minute is set.
 W does not return a continue or any kind of response for 5 seconds
 P marks that worker dead meat

 C asks for http://myserver/someDatabaseBackedThing
 P matches and forwards this request to W with the expect continue and
 specified 5 sec expect-continue timeout.  A separate overall proxy
 timeout of 1 minute is set.
 W returns a continue but then begins to process the request
 (CGI/JavaServlet/PHP whatever to the database)
 W spends more than a minute and the proxy request times out

 The case of a dead connector things back out rather nicely and its
 clearly distinguishable from a bad script.

 -Andy

 On Mon, Aug 16, 2010 at 2:52 PM, Jim Jagielski j...@jagunet.com wrote:

 On Aug 16, 2010, at 1:42 PM, Paul Querna wrote:

 On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski j...@jagunet.com wrote:

 On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote:

 This basicly sums up the downsides of this approach I see as well.

 IMHO to avoid a spec violation we can only add the Expect header to
 requests with request bodies. OTOH these requests hurt most when they
 fail as we cannot sent the request body for a second time, because
 we do not have it any longer available in most situations and requests
 with request bodies are usually not idempotent.

 On the second issue we only need to take care that we do not add something
 already there and remove something that client expects to see.

 One last thing I see is that this only works if the backend is HTTP/1.1:

 8.2.3

 - If the proxy knows that the version of the next-hop server is HTTP/1.0 
 or lower
  , it MUST NOT forward the request and it MUST respond with a 417 
 (Expectation Failed)
  status.

 Yes, the code itself is aware of the limitations of 100-Continue,
 including version and req body considerations... It's not ideal,
 but it's better than the OPTIONS method which I played around
 with earlier...

 Still I think it's useful to add it in, have it disabled by
 default, and see how far we can take it...

 I think the only options really are a status URL, with a regex match,
 so you can test if the backend has an expected content, and having the
 backends advertise/notify the proxy that they are alive.


 Well, OPTIONS is the defacto HTTP ping but it's also considered
 a request (afaik), and so things like keepalives, etc matter.
 That was the issue I ran into is that checking with OPTIONS
 doesn't totally remove the problem, esp for non-keepalive
 connections or one-shots, and then you need to worry if that
 last OPTIONS forced a connection that was in keepalive mode
 to close and all that junk

 What I just committed is not the ideal solution, but like you
 said, the real way to do this is non-trivial with the current
 architecture...

Re: httpd 2.3.7 as beta?

[Paul Querna]

On Tue, Aug 10, 2010 at 1:01 PM, Jim Jagielski j...@jagunet.com wrote:
 Subject for discussion...  Does truck look good enough
 for Beta?

 In either case, as alpha or beta, I plan to RM this next week.

It has been stable on www.apache.org once we turned off sendfile.
There was some discussion about chaging that by default, but I don't
think that blocks it for beta.

I think it might be worth seeing if there are any things we want to
remove too, but as long as we have a couple betas, it doesn't need to
happen before the first, just before GA.

Anyways, +1, do it :)

Thanks,
Paul

Re: [VOTE] Release httpd 2.2.16

[Paul Querna]

Plenty of +1s, one +0.9 and no -1s, so I'll start syncing the files
out to the mirror network, and prep the announcement mail for
tomorrow.

Thanks everyone for voting and testing

On Wed, Jul 21, 2010 at 11:45 AM, Paul Querna p...@querna.org wrote:
 Test tarballs for Apache httpd 2.2.16 are available at:
  http://httpd.apache.org/dev/dist/

 Your votes please;

  +/- 1
  [  ]  Release httpd-2.2.16

 Vote closes at 02:00 UTC on Saturday July 24 2010.

 Thanks,

 Paul

Re: [VOTE] Release httpd 2.2.16

[Paul Querna]

On Thu, Jul 22, 2010 at 12:23 AM, Rainer Jung rainer.j...@kippdata.de wrote:
 On 22.07.2010 07:46, Ruediger Pluem wrote:


 On 07/22/2010 06:10 AM, William A. Rowe Jr. wrote:

 On 7/21/2010 10:09 PM, Rainer Jung wrote:

 On 22.07.2010 04:52, Paul Querna wrote:

 Ack-- I could re-tag with libtool 1.x, if we don't want to ship a
 modified apr-util.

 I always use an external expat it seems :(

 Thoughts?

 For the ASF release re-tag would be enough. There's a few people though,
 that already ran into the same problem with 2.2.15 (BZ49053). It's
 possible some distros might run buildconf before providing their source
 bundles, but it could also just have been those users themselves. The
 info given in the issue does not clarify this.

 Since the buildconf bug itself is not a regression and there are well
 known workarounds I would say re-tag and fix with 2.2.17.

 AIUI - this is a reroll, but the tag remains the same?  If the source
 files
 in svn are nonvolatile, then going with libtool 1.x might be the ticket.



 +1 to reroll. The tag can stay the same.

 Don't know why Paul and me both used the wording re-tag when talking about a
 procedure that doesn't change the svn sources. So yes, I meant re-roll.

re-rolled using libtool 1.x, tarballs in the same places.

I'll bump up the end of the vote to end of day Saturday UTC if that
helps more people try it out.

Re: [VOTE] Release httpd 2.2.16

[Paul Querna]

On Wed, Jul 21, 2010 at 11:45 AM, Paul Querna p...@querna.org wrote:
 Test tarballs for Apache httpd 2.2.16 are available at:
  http://httpd.apache.org/dev/dist/

 Your votes please;

  +/- 1
  [+1]  Release httpd-2.2.16

 Vote closes at 02:00 UTC on Saturday July 24 2010.

FTR, +1

Has been running on eris/harmonia just fine (svn.apache.org), seems
happy and no new problems there.

Thanks,

Paul

[VOTE] Release httpd 2.2.16

[Paul Querna]

Test tarballs for Apache httpd 2.2.16 are available at:
 http://httpd.apache.org/dev/dist/

Your votes please;

 +/- 1
 [  ]  Release httpd-2.2.16

Vote closes at 02:00 UTC on Saturday July 24 2010.

Thanks,

Paul

Re: [VOTE] Release httpd 2.2.16

[Paul Querna]

Ack-- I could re-tag with libtool 1.x, if we don't want to ship a modified 
apr-util.

I always use an external expat it seems :(

Thoughts?

On Jul 21, 2010, at 7:42 PM, Rainer Jung rainer.j...@kippdata.de wrote:

 On 22.07.2010 04:17, Rainer Jung wrote:
 On 21.07.2010 20:45, Paul Querna wrote:
 Test tarballs for Apache httpd 2.2.16 are available at:
 http://httpd.apache.org/dev/dist/
 
 Your votes please;
 
 +/- 1
 [ ] Release httpd-2.2.16
 
 Vote closes at 02:00 UTC on Saturday July 24 2010.
 
 Just a quick info in case someone else also runs into this: there's a
 problem with the builtin expat configure because buildconf.sh was run
 using libtool 2 but isn't really ready for this. It's a regression from
 2.2.15, which has been rolled using libtool 1.
 
 Suggested patch:
 
 http://people.apache.org/~rjung/patches/expat-libtool2.patch
 
 Regards,
 
 Rainer

rolling 2.2.16 tomorrow

[Paul Querna]

Hi,

I'll start the tagging + voting on 2.2.16 tomorrow unless everyone
starts screaming..

Thanks,

Paul

2.3 upgrade on apache.org

[Paul Querna]

www.apache.org is now running trunk @ r965127, using the Event MPM on
FreeBSD 8.1, on a new x86 box.

Previously it was running on Solaris 10, with 2.2.x on sparc t2000s.

I have also enabled OCSP stapling on the SSL side:
  https://www.apache.org/

Anyways, I've made a list of the 2.3-ish issues seen during the upgrade.

httpd itself:
 - Using the Define directive to enable SSL was a bad idea.  The SSL
init code was only being called once in post_config instead of twice
This is only 'new' because the Define directive is new, so I tried to
use it.  Example of how it was used:
  IfDefine MACHINE_NAME
 Define SSL
 Listen 1.2.3.4:
  /IfDefine

  IfDefine SSL
LoadModule ssl_module ..
  /IfDefine

We do -D MACHINE_NAME at the command line, and I was hoping to just
enable SSL from within the config file, but that didn't work. Adding
-D SSL to the command line fixed the issue.

- Lots of warnings in our configurations about Ignoring deprecated
use of DefaultType.

- Infra already had lots of IfVersion blocks for most 2.3 authn/z
changes, and those seem to stil be working fine.

3rd party:

- APR's detection of BDB was funky again, I had --with-dbm=db48, which
it was happy about, but until I added --with-berkeley-db=/usr/local,
it wouldn't actually compile up the shared objects for the DB DBM, but
configure reported success.

- mod_wsgi:  Needed to comment out 2 lines debug logging, that were
accessing server_rec-loglevel (which has been removed from 2.3.x).

- mod_mbox/mod_allowmethods/mod_asf_cgi: Needed build system
adjustments to not look for apr-util.

Surprisingly painless upgrade after I figured out the mod_ssl config
issue; Most of the work was around moving Solaris - FreeBSD for our
various rsyncs and crontabs,  of course let infra know if you see
anything busted!

Thanks,

Paul

Re: 2.3 upgrade on apache.org

[Paul Querna]

A small update:

We thought the load average was a little high, in the 70+ range.  We
observed massive CPU usage from the httpd processes, but IO wise the
machine was fine -- tons of IO bandwidth to go around -- it seemed to
be something spinning inside httpd itself.

At first I thought it might of been the event mpm bug, so with the
awesome MPMs as a module, we switched to worker.

Didn't help.

I dug out ktrace, and started seeing what we were doing.

Every httpd processes I looked at was spinning on sendfile:

33893 httpdCALL
sendfile(0x33,0x23,0x1d3000,0xbe6201,0x7d1e9bd0,0x7d1e9bf8,invalid=0)
33893 httpdRET sendfile -1 errno 35 Resource temporarily unavailable

ktrace/dtrace dumps available to any committer who wants to take a
look.  A similar problem is described in this thread from 2002, about
running 2.0.x on Daedalus:
  http://www.mail-archive.com/dev@httpd.apache.org/msg04928.html

I've started tuning up the FreeBSD sysctls for network buffers etc,
but it didn't seem to have a significant effect.

We have now disabled Sendfile on apache.org, and the load average
dropped from ~80 to 0.35.

On Sun, Jul 18, 2010 at 3:08 AM, Paul Querna p...@querna.org wrote:
 www.apache.org is now running trunk @ r965127, using the Event MPM on
 FreeBSD 8.1, on a new x86 box.

 Previously it was running on Solaris 10, with 2.2.x on sparc t2000s.

 I have also enabled OCSP stapling on the SSL side:
  https://www.apache.org/

 Anyways, I've made a list of the 2.3-ish issues seen during the upgrade.

 httpd itself:
  - Using the Define directive to enable SSL was a bad idea.  The SSL
 init code was only being called once in post_config instead of twice
 This is only 'new' because the Define directive is new, so I tried to
 use it.  Example of how it was used:
  IfDefine MACHINE_NAME
     Define SSL
     Listen 1.2.3.4:
  /IfDefine

  IfDefine SSL
    LoadModule ssl_module ..
  /IfDefine

 We do -D MACHINE_NAME at the command line, and I was hoping to just
 enable SSL from within the config file, but that didn't work. Adding
 -D SSL to the command line fixed the issue.

 - Lots of warnings in our configurations about Ignoring deprecated
 use of DefaultType.

 - Infra already had lots of IfVersion blocks for most 2.3 authn/z
 changes, and those seem to stil be working fine.

 3rd party:

 - APR's detection of BDB was funky again, I had --with-dbm=db48, which
 it was happy about, but until I added --with-berkeley-db=/usr/local,
 it wouldn't actually compile up the shared objects for the DB DBM, but
 configure reported success.

 - mod_wsgi:  Needed to comment out 2 lines debug logging, that were
 accessing server_rec-loglevel (which has been removed from 2.3.x).

 - mod_mbox/mod_allowmethods/mod_asf_cgi: Needed build system
 adjustments to not look for apr-util.

 Surprisingly painless upgrade after I figured out the mod_ssl config
 issue; Most of the work was around moving Solaris - FreeBSD for our
 various rsyncs and crontabs,  of course let infra know if you see
 anything busted!

 Thanks,

 Paul

Re: A 2.3.7 this month?

[Paul Querna]

On Wed, Jul 14, 2010 at 1:51 PM, Jim Jagielski j...@jagunet.com wrote:
 On Wed, Jul 14, 2010 at 10:25:25PM +0200, Stefan Fritsch wrote:
 Hi,

 what do you think about releasing 2.3.7 in the next 2 weeks, and
 hopefully make it a beta? Are there any open issues that are not in
 STATUS?


 I'd be up for another release, beta or not, and offer to RM

+1 to another release.

I'm also happy to RM it, I've been trying to get 2.3.x running on
www.apache.org, and hopefully will get some time this weekend to push
up a few patches we needed.

-Paul

Re: A 2.3.7 this month?

[Paul Querna]

On Wed, Jul 14, 2010 at 1:53 PM, Sander Temme scte...@apache.org wrote:
 Would OSCON be a good moment to branch 2.4.x?  Or aren't we there yet?  Are 
 the issues between us and branching in STATUS?

I don't think of any big ones, other than just the pain of back
porting to another branch from trunk. I believe we are at least 2
betas away from being stable enough -- OCSP stapling has a few nasty
bugs, and I'm running into problems with socache on FreeBSD 8.  I
guess those are things to add to STATUS

I think that we should just encourage everyone to not drop big
features into trunk without some discussion... CTR with some
mild-stabilization :)

I'd suggest roll this next one as beta, wait a few weeks, and then
consider a 2.4.x branch point.

-Paul

ocsp stapling global mutex

[Paul Querna]

Hi,

I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
that in the common case path, we will always lock a global mutex.

I don't see why this is needed for the cache hit case that uses
non-SHM cache providers.

In fact, modssl_dispatch_ocsp_request, which is called on a cache
miss, already has a serialize_request, so I'm not sure why there is a
global mutex at all, even for cache updates.

It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
the global mutex should only be used if (mc-stapling_cache-flags 
AP_SOCACHE_FLAG_NOTMPSAFE) is true?

Thoughts?

Thanks,

Paul

Re: server-status and privacy

[Paul Querna]

On Tue, Jun 22, 2010 at 6:23 PM, Nicholas Sherlock n.sherl...@gmail.com wrote:
 On 22/06/2010 12:40 a.m., Jim Jagielski wrote:

 There have been a few reports regarding how server-status leaks
 info, mostly about our (the ASF's) open use of server-status and
 how IP addresses are exposed.

 I'm thinking about a patch that adjusts server-status/mod_status
 to have a public vs. private setting... Public would be to
 have IP addresses exposed as public info; private would be to
 not expose 'em (keep 'em private).

 Comments?

 I can't believe when I informed apache.org of this issue 70 days ago, that
 the immediate response wasn't simply to disable server-status or restrict it
 to clients from within Apache's network. It is a completely unreasonable
 violation of your customer's privacy to broadcast their IP addresses and
 viewing habits.

1) This configuration has been present on apache.org for at least 10
years, probably longer.  Maybe the rest of the internet's expectation
of IP address privacy has changed in that time, but the server-status
on apache.org has been there for a long time.

2) There is no 'apache network' to restrict access from -- the real
asf server admins are random people all over the world.

3) I'm not really sure this belongs on d...@httpd at all,
infrastruct...@apache.org is likely where you want to send complaints
of this type.  A feature request to add obfuscation to mod_status
might be interesting to some, but its not really related to
apache.org's configuration.

4) How is it a completely unreasonable violation of privacy to show
request urls to a public website, with zero private content or
anything even remotely sensitive, and associate that with an IP
address?  IP address X was looking up how to configure Hadoop... and
that harms someone how?   We aren't a search engine, we don't host
anything that is embarrassing or private on the public server-status
pages.

Thanks,

Paul

Re: mod_authn_cache

[Paul Querna]

On Wed, Jun 16, 2010 at 3:29 PM, Nick Kew n...@webthing.com wrote:
 I thought we had a mod_authn_cache, but it seems it only exists in the
 old 2.1 authn stuff at sourceforge!

 Just thinking about hacking this up, and wondering how best to do it.
 Basic shape seems straightforward enough:

 1.  Make it a provider like the standard mod_authn_
 2.  Configure it ahead of anything heavyweight like dbd.
 3.  Export an optional function for other mod_authn_* modules to cache
    credentials they've looked up.
 4.  Timestamp everything in cache, and provide a configurable timeout.

 But how to implement the cache itself is less clear.  The simplest solution
 would be to hijack mod_authn_dbm and add a cacheing function and 
 configuration.
 But the new socache framework presents an alternative, and an option for users
 of threaded MPMs to run a per-process cache would add value.

 Thoughts?


You can take the mod_authn_cache from SF as a baseline; its mine, I'm
happy to donate it to the ASF.

I would suggest just using mod_authn_cache, rippng out its own caching
stuff, and using mod_socache.

Re: C as config

[Paul Querna]

On Fri, Jun 4, 2010 at 3:21 PM, Akins, Brian brian.ak...@turner.com wrote:
 All of you folks who have to answer user questions, go ahead and ready your
 hate mail :)

 I've been playing some with Varnish (long story) and lots of people seem to
 like it.  The config language (VCL) is just a thin wrapper on top of C.
 Heck, you can just write C inline.

 Also, I do a good bit with Lua -- in httpd and other projects.  Every time I
 run profiles on this stuff, Lua is always 3 out of the top 5 cpu consumers.
 And lots of it is just the language itself (all the table look-ups) and we
 highly optimized our method dispatches (using apr_hash, even had a version
 using gperf). Now this is probably just fine for mere mortals, but it has
 always bothered me.  We always meant to go back and write higher level
 modules based on the low level Lua bindings, but we never did and we have
 several non programmers who are happily writing configs in Lua.

Are you using LuaJIT 2?  The performance numbers its putting up seemed
very impressive.

http://luajit.org/luajit.html

Re: C as config

[Paul Querna]

On Jun 4, 2010, at 4:32 PM, Akins, Brian brian.ak...@turner.com  
wrote:



On 6/4/10 7:30 PM, Paul Querna p...@querna.org wrote:

Are you using LuaJIT 2?  The performance numbers its putting up  
seemed

very impressive.


Yes and meh...



 bummer.


The most iteresting thing in this space since VCL was created is the  
development of LLVM  clang.  It seems like if you wanted to build  
this these days, that would be where to start, though including an  
entire compiler stack does seem both a dainting task, and one that  
creates many other issues.



I guess if the first approach was close to generating a .so based on a  
config file input, it might be a better archtiecture.





--
Brian Akins

Re: What's next for 2.2 and 2.3/trunk?

[Paul Querna]

On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski j...@apache.org wrote:
 Considering that 2.3/trunk is back to limbo-land, I'd like
 to propose that we be more aggressive is backporting some
 items. Even if under experimental, it would be nice if slotmem
 and socache were backported. I also like the refactoring of
 the providers for proxy in trunk as compared to 2.2, but
 last time I suggested it, it looked like 2.3/2.4 was close(r)
 to reality...

 comments...?

2.2 came out 5.5 years ago.  I strongly support shipping 2.4.

i've not had time to try to ship more alpha/betas.  Does anyone else
have time to head up RMing it?

Its easy once you get it down, 2 commits, one run of of the release
shell script, and 3 emails.

Re: pointer to info on GCD MPM

[Paul Querna]

On Wed, May 12, 2010 at 1:30 PM, Jeff Trawick traw...@gmail.com wrote:
 (GCD as in Grand Central Dispatch)

 See http://lists.macosforge.org/pipermail/libdispatch-dev/2010-May/000352.html


I think its pretty cool that it works.

I think it might be interesting to include in trunk, though I have no
illusions about having enough time to contribute significantly to
maintaining it :)

Re: IDE for Apache HTTP server development?

[Paul Querna]

On Fri, Apr 30, 2010 at 6:43 AM, Dan Poirier poir...@pobox.com wrote:
 Does anyone have recommendations for an IDE they use for development on
 the server?  Preferably that runs on Mac, or else Linux.

 I haven't been a big fan of IDEs, being happy with Emacs for years, but
 I've found for Java development, I'm clearly more productive in Eclipse
 than Emacs.

 So I'm wondering if I'm missing something similar that could be used
 when I work on Apache.

I've just been using Xcode.  I had a script at one time that generated
a xcode project file from a list of files, but now days I just use
`xed` from a terminal to open files to edit:
http://www.devworld.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/xed.1.html

you can also xed on a directory to bring up the xcode
directory/project browser thing.

hth,
Paul

Re: Undocumented core directive: Protocol

[Paul Querna]

On Thu, Feb 25, 2010 at 5:20 AM, Eric Covener cove...@gmail.com wrote:
 On Thu, Feb 25, 2010 at 8:03 AM, Dan Poirier poir...@pobox.com wrote:

 1) When you use the Protocol directive, which listening ports is it
 applied to?

 2) Why would you choose to use the Protocol directive, instead of adding
 the protocol to the Listen directive?

 Looking at this cold, I think the answer to this is that Protocol is 
 per-vhost.

I'm not sure it should be, IIRC protocol was introduced before
protocols on the Listener command, and  their only practical use is
deciding if we should use kernel level accept filters.

I'm honestly thinking that it could be possible to kill the command,
if people are happy with having to use the listen command to spec it.

Because it 'inherits' the protocol form the Listen Directive, these
two configurations are functionally identical:
Listen 443
VirtualHost *:443
  Protocol https
   ...
/VirtualHost

And:
Listen 443 https
VirtualHost *:443
   ...
/VirtualHost

So, I kinda think the value isn't there anymore, and maybe we should
consider just removing the directive, and tell people to use the
protocol on the listen command?

Thoughts?

Thanks,

Paul

unsupported compression issue seen in 2.3.5-alpha

[Paul Querna]

Hi,

For www.apache.org (and all TLP websites), we have received increased
reports about invalid compression issues.

Previously, we have heard about sporadic issues with Firefox only, and
these were always resolved by users by clearing their cache, this
issue seems to be a good description of it:
https://bugzilla.mozilla.org/show_bug.cgi?id=366023

However, the newest reports have been about multiple browsers,
Firefox, Chrome, Safari, and IE8, all reporting the issue at the same
time.  This makes be believe that the problem is something on the
server side.

If you look at the history of mod_deflate:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_deflate.c?view=log

r821471 is the only change in the last year -- and it changes how
buckets are used -- and I view it as suspect in relation to the volume
of reports we have received from users, but we don't have any firm
evidence.

Any ideas?

Thanks,

Paul

Re: clogging filters and async MPMs

[Paul Querna]

On Thu, Feb 4, 2010 at 6:14 AM, Bryan McQuade bmcqu...@google.com wrote:
 Hi,
 I'm reading through the httpd code and I notice that async MPMs will fall
 back to sync mode in the presence of clogging input filters (at least I
 think I've got that right).
 I understand that mod_ssl is a clogging filter.

Yep
 What does it mean to be a clogging filter? How does this break async MPMs?

It means the filter buffers in such a way that it might have data
inside it, but a poll() on the socket will never return active when it
has data ready.  It also has to do with filters that change the
read/write flow -- we currently don't have a way for an output filter
for example to say come back to me when there is data available to
READ.  This is specifically the mod_ssl problem, because of the SSL
protocol, you often need to do a write before you can read, or vice
versa.

 What would it take to make mod_ssl a non-clogging filter?

Basically needs two things:
1) Never buffer data inside ssl (feasible I believe)
2) Create a new way for a filter deep inside the chain to indicate we
need to wait for a read/write ability on a socket -- this
fundamentally is why a Serf bucket model is better than our chained
filters.  An alternative  approach would be changing the flow so
filters don't directly call the next filter, putting the core back in
control of filter flow, but this is still a non-trivial project.

HTH,

Paul

Apache HTTP Server 2.3.5-alpha Released

[Paul Querna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apache HTTP Server 2.3.5-alpha Released

The Apache Software Foundation and the Apache HTTP Server Project are
pleased to announce the release of version 2.3.5-alpha of the Apache HTTP
Server (Apache).  This version of Apache is principally an alpha release
to test new technology and features that are incompatible or too large for
the stable 2.2.x branch. This alpha release should not be presumed to
be compatible with binaries built against any prior or future version.


Apache HTTP Server 2.3.5-alpha is available for download from:

  http://httpd.apache.org/download.cgi

Apache 2.3 offers numerous enhancements, improvements, and performance
boosts over the 2.2 codebase.  For an overview of new features
introduced since 2.3 please see:

  http://httpd.apache.org/docs/trunk/new_features_2_4.html

Please see the CHANGES_2.3 file, linked from the download page, for a
full list of changes.

This release includes the Apache Portable Runtime (APR) version 1.4.2
and APR-Util version 1.3.9 in a separate -deps tarball.  The APR libraries
must be upgraded for all features of httpd to operate correctly.

This release builds on and extends the Apache 2.2 API.  Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.3, and require minimal or no source code changes.

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAkth7HAACgkQ94h19kJyHwDjxwCeP4E1Xpts6XJO3wua1Hm2Ds8A
hi0An2MCpiAdVGKQLjrK5ixxzaAq1kIg
=+YL2
-END PGP SIGNATURE-

Re: [VOTE] Release httpd 2.3.5-alpha

[Paul Querna]

On Tue, Jan 26, 2010 at 11:13 AM, Sander Temme scte...@apache.org wrote:

 On Jan 21, 2010, at 2:34 PM, Paul Querna wrote:

 Test tarballs for Apache httpd 2.3.5-alpha are available at:
  http://httpd.apache.org/dev/dist/

 Your votes please;

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

 Vote closes at 18:00 UTC on Monday January 25 2010.

 This includes a bundle of APR 1.4.2, and APR-Util 1.3.9.

 I see 4x +1 (Paul, Jeff, Gregg and myself) and no -1s... shall we toss this 
 over the wall?

 What do we need to do to achieve our goals with this Alpha?

Pushed to the dist network, will do release announcement in 24 hours.

Re: [VOTE] Release httpd 2.3.5-alpha

[Paul Querna]

On Thu, Jan 21, 2010 at 2:34 PM, Paul Querna p...@querna.org wrote:
 Test tarballs for Apache httpd 2.3.5-alpha are available at:
  http://httpd.apache.org/dev/dist/

 Your votes please;

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

 Vote closes at 18:00 UTC on Monday January 25 2010.

My own +1, seems to be good for the ASF production web servers, good
enough for an Alpha. (also been fine with light testing on osx)

Thanks,

Paul

[VOTE] Release httpd 2.3.5-alpha

[Paul Querna]

Test tarballs for Apache httpd 2.3.5-alpha are available at:
  http://httpd.apache.org/dev/dist/

Your votes please;

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

Vote closes at 18:00 UTC on Monday January 25 2010.

This includes a bundle of APR 1.4.2, and APR-Util 1.3.9.

Thanks,

Paul

Re: [VOTE] Release httpd 2.3.5-alpha

[Paul Querna]

On Thu, Jan 21, 2010 at 2:34 PM, Paul Querna p...@querna.org wrote:
 Test tarballs for Apache httpd 2.3.5-alpha are available at:
  http://httpd.apache.org/dev/dist/

 Your votes please;

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

 Vote closes at 18:00 UTC on Monday January 25 2010.

 This includes a bundle of APR 1.4.2, and APR-Util 1.3.9.

aurora.apache.org, aka www.apache.org has been upgraded.

No problems so far!

Re: next alpha, this Wednesday?

[Paul Querna]

I think i'll take the 1.4.2 APR tag, and try to use APR-Util 1.3.9

On Wed, Jan 20, 2010 at 3:17 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
 On 1/20/2010 4:56 PM, Sander Temme wrote:

 On Jan 20, 2010, at 9:42 AM, William A. Rowe Jr. wrote:

 On 1/20/2010 10:01 AM, Sander Temme wrote:

 And the %lld printf formatter on MacOSX... small, but it does break a test.

 That's fixed on the branch, or no?  About to tag 1.4.2.

 I'm about to get on a flight, will test once under way.

 Sorry - missed it.  It's tagged, and we'll move along to fix more bugs with
 the next release.

 I don't see a whole lot of reason to hold up a release if nobody on the 
 platform
 has cared to patch a known flaw in 3 months :)

 We can sort of count on a 1.4.3 soon, I have a request to fix a win32 edge 
 case
 for subversion that didn't merit destabilizing this release, but would be a
 great fix to have for windows users, before subversion 1.7 is released.

next alpha, this Wednesday?

[Paul Querna]

I'm planning roughly on doing another 2.3.x-alpha tag on this late
Wednesday, January 20th.  Should give us enough time to vote on it
over the weekend, and ship it out on Monday/tuesday next week, during
the hackathon at G.

Objections?

Thanks,

Paul

Re: next alpha, this Wednesday?

[Paul Querna]

On Tue, Jan 19, 2010 at 4:41 PM, Sander Temme scte...@apache.org wrote:

 On Jan 19, 2010, at 1:37 PM, Paul Querna wrote:

 I'm planning roughly on doing another 2.3.x-alpha tag on this late
 Wednesday, January 20th.  Should give us enough time to vote on it
 over the weekend, and ship it out on Monday/tuesday next week, during
 the hackathon at G.

 Do we have an APR to roll into a *-deps, or are we canning the notion of 
 *-deps until such things solidify?

For APR, we can use 1.4.1:
http://svn.apache.org/repos/asf/apr/apr/tags/1.4.1/

For APR-Util, I think we still need to use a snapshot, as there has
not been a suitable release or tag.

Thanks,

Paul

Re: [PATCH] Allow AuthZ providers to supply group data to other modules

[Paul Querna]

On Thu, Dec 31, 2009 at 9:06 AM, Christian Seiler chris...@gmx.net wrote:
 Hi,

 My approach is thus to provide a simple mechanism within the Apache API
 which allows any authz module to export group information to other
 modules. With this mechanism in place, it is possible to change
 mod_authz_svn in a way that allows it to use a generic group storage
 that it fetches from any used Apache authz module. The change in
 mod_authz_svn is of course not the focus of this posting.

 Is there nobody who wants to comment on my previous email?

Conceptually, I think this is a great idea.  I think we should do this.

The patch is quite big/monolithic though, and that discouraged me from
taking time to review it all. I'll try to dig into it this weekend
hopefully.

Thanks,

Paul

Re: Per module LogLevel configuration

[Paul Querna]

On Tue, Dec 29, 2009 at 1:30 AM, Ruediger Pluem rpl...@apache.org wrote:
 On 28.12.2009 18:28, Stefan Fritsch wrote:
 On Monday 28 December 2009, Paul Querna wrote:
 You describe the internal arg processing.  Keep in mind that fn
 args aren't conditionally processed, they must be created before
 being passed to the function.  If we can dodge that with a module
 query 'is mod_foo at loglevel debug here?' then we can optimize
 this considerably.
 Yes, see the implementation of the Noit Logger which I linked to,
  it uses a Macro to check if a logger is enabled, so you don't have
  the function arg prep/frame overhead if a logger isn't enabled.


 This would also make it possible to define the macro in a way that
 disables debug logging at compile time, just as Bill wanted.

 However, the way reconoiter does it requires variadic macros
 (http://en.wikipedia.org/wiki/Variadic_macro):

 #define APLOG(file, line, loglevel, server, ...) \
 do { if (server-loglevel = loglevel) \
      ap_log_error(file, line, loglevel, server, __VA_ARGS__) \
 } while (0)


 But variadic macros are only part of C99. Is it ok to drop support for
 older, pre-C99 compilers in httpd?

 I think that would cancel support for some platforms (Netware ???).
 So IMHO no.

Pretty much everything else has a c99 compiler these days.  On
platforms that don't, you could easily fallback to this:

#ifdef HAVE_VA_ARGS
#define apL(stream, fmt, ...) if ((stream)-enabled) { \
   stream-log(fmt, __VA_ARGS__) \
}
#else
#define apL ap_stream_log
#endif

Where ap_strream_log is a normal function with a signature matching apL.

Yes, it means on netware, its slower, but no slower than what we do
today, and on most other platforms, it would be faster than what we do
today.

Re: Per module LogLevel configuration

[Paul Querna]

On Sun, Dec 27, 2009 at 11:08 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
 Dan Poirier wrote:

 Looking at log_error_core(), it appears that if the logging level is set
 to disallow a particular message from being logged, that
 log_error_core() returns before doing any argument processing.  So the
 overhead would only consist of a few function calls, and my sense would
 be that saving that wouldn't make a big difference.

 You describe the internal arg processing.  Keep in mind that fn args aren't
 conditionally processed, they must be created before being passed to the
 function.  If we can dodge that with a module query 'is mod_foo at loglevel
 debug here?' then we can optimize this considerably.

 A minimum vector is per-vhost-per-module, but per-dir-per-module would be
 even better :)  At that granularity, and adding per-mod forensics, the user
 can be grabbing lots of detail on one specific module in the single context
 that is causing that module to misbehave.

Yes, see the implementation of the Noit Logger which I linked to, it
uses a Macro to check if a logger is enabled, so you don't have the
function arg prep/frame overhead if a logger isn't enabled.

Re: Per module LogLevel configuration

[Paul Querna]

On Wed, Dec 23, 2009 at 4:14 AM, Stefan Fritsch s...@sfritsch.de wrote:
 Hi,

 when debugging problems, one needs detailed debug logging of the
 involved functions. Unfortunately, some modules (especially mod_ssl)
 log so much that switching to LogLevel debug in a production
 environment is often impractical. Therefore I think it would be very
 useful if one could set the loglevel per module.

+1 in concept, this is one of the most annoying parts of the logging
subsystem today!

An alternative implementation would be something along the lines of
how reconnoiter does logging:
https://labs.omniti.com/trac/reconnoiter/browser/trunk/src/utils/noit_log.h

This would definitely be a larger rewrite in general for logging, but
would be much more flexible in the long run, but I have grown fond of
how reconoiter's logging subsystem has worked.

Most modules would do this in their init function:

dlog = ap_log_stream_find(mod_foo/debug)
elog = ap_log_stream_find(mod_foo/error)

Where dlog/elog are static globals for that file.  If the logging
system is disabled for that module, logging in the module is then done
like this:

apL(dlog, foo is wrong: %d, bar);

Our current system only has emerg, alert, crit, error, warn, notice,
info, debug, but because they are not configurable per-module, they
are difficult to use effectively, I think in general if we had
per-module logging, we could easily get by with just critical, error,
info,  and debug.

 Also, there is some need to have finer control over what is logged, as
 demonstrated by modules with their own log configuration
 (SSLLogLevelDebugDump, DumpIOLogLevel, RewriteLogLevel, ...). I would
 introduce some new loglevels above debug (maybe trace1 to trace6
 corresponding to the rewrite log levels) and use these for the most
 detailed messages. Together with the per module log level, one could
 then remove the special per module config directives.

 What I want is the admin being abled to configure something like this:

        LogLevel info ldap=debug authnz_ldap=debug ssl=warn rewrite=trace4

 For the implementation I thought of some loglevel vector similar to
 the construct used by ap_get_module_config. There should then be a
 ap_get_module_loglevel and the ap_log_*error functions would get the
 module_index as additional parameter. To make things somewhat source
 compatible, one could redefine APLOG_MARK to something like
 __FILE__,__LINE__,GLOBAL, i.e. most modules could be compiled without
 changes (but would then use the global log level). To add support to a
 module, something like

        #define APLOG_MARK_LDAP __FILE__,__LINE__,ldap_module-module_index

 and a global search and replace would be enough for most modules (or
 one could even redefine APLOG_MARK in the module source).

hmm, I'm not sure I really like having to redefine APLOG_MARK in every
file.. It would be nice if we could build the macro into the module
declaration perhaps?

Thanks,

Paul

Re: svn commit: r892678 - in /httpd/httpd/trunk: CHANGES server/protocol.c

[Paul Querna]

On Mon, Dec 21, 2009 at 2:39 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:


 -Original Message-
 From: nicholas@sun.com [mailto:nicholas@sun.com] On
 Behalf Of Nick Kew
 Sent: Montag, 21. Dezember 2009 10:36
 To: dev@httpd.apache.org
 Subject: Re: svn commit: r892678 - in /httpd/httpd/trunk:
 CHANGES server/protocol.c


 On 21 Dec 2009, at 07:22, Ruediger Pluem wrote:

  Why bytes_handled - 1 and not bytes_handled?

 Using bytes_handled - 1 breaks a lot of tests in the perl test framework.
 Using bytes_handled instead fixes this.
 Please reconsider and fix.

I am also slightly concerned about changing the behavoir of
ap_rgetline_core in regards to embedded NULL bytes, since this is not
just used by HTTP protocol handlers, it appears it could easily be
used by other protocols... at a minimum I think there should be a
comment in the header docs about this behavior change?

Re: svn commit: r892678 - in /httpd/httpd/trunk: CHANGES server/protocol.c

[Paul Querna]

On Mon, Dec 21, 2009 at 4:41 PM, Nick Kew n...@webthing.com wrote:
 Paul Querna wrote:

 On Mon, Dec 21, 2009 at 2:39 AM, Plüm, Rüdiger, VF-Group
 ruediger.pl...@vodafone.com wrote:

 Please reconsider and fix.

 Done, thanks.

 I am also slightly concerned about changing the behavoir of
 ap_rgetline_core in regards to embedded NULL bytes, since this is not
 just used by HTTP protocol handlers, it appears it could easily be
 used by other protocols... at a minimum I think there should be a
 comment in the header docs about this behavior change?

 From protocol.c
 /* Get a line of protocol input, including any continuation lines
  * caused by MIME folding (or broken clients) if fold != 0, and place it
  * in the buffer s, of size n bytes, without the ending newline.

 From http_protocol.h
 /**
  * Get the next line of input for the request

 Are you saying it might be used in a protocol with RFC822-family
 line-based headers but where NULL is allowed?  Any examples?

 I agree with your point that I should have commented it.
 I'll do that if you're not going to veto the patch.

I'm happy enough with a comment in the header file mentioning the
embedded NULL byte behavior, which is kinda 'weird' because it passes
back a length size_t -- hence why I think it should be documented in
the interface documentation.