Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On Wed, Jun 2, 2010 at 4:23 PM, Joe Orton jor...@redhat.com wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) +1. -- justin
Re: mod_deflate handling of empty initial brigade
Bryan McQuade wrote: Are there any cases where it's important for ap_pass_bridgade to pass on an empty brigade? Doesn't sound like it, but since this is a core library change I want to double check. When handling a CONNECT request, the response will have no body. In mod_proxy, the CONNECT handler currently skips most filters and writes via the connection filters. However there is a block of #if 0 code which intends to send only a FLUSH bucket down the filter chain. That's not quite the case of an entirely empty brigade, but it seems close enough to warrant highlighting. Thanks, Paul
Re: mod_proxy and chunked encoding
I cannot try another version in the environment where I have the problem :-( But I can't find any (explicit) fix for it in newer versions... Original Message Subject: RE: mod_proxy and chunked encoding Date: Wed, 2 Jun 2010 14:34:43 +0200 From: Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com To: dev@httpd.apache.org, nickgea...@gmail.com -Original Message- From: Nick Gearls Sent: Mittwoch, 2. Juni 2010 14:06 To: Development Apache Subject: mod_proxy and chunked encoding Hello, Although I can see a lot of problems related to chunked encoding, it is not clear to me if it is correctly supported in latests versions. During tests with 2.2.4, I found the following problem: when the 2.2.4 is fairly old. Have you tried with a more recent version? Regards Rüdiger
Module build defaults for trunk
Reading the feedback on the modules list I posted got me into thinking: 1) Should static module linking be still the default for httpd building? Of course the question is only relevant for platforms which allow dynamic linking and if we have APR_HAS_DSO. I know that static linking is expected to be more secure (but we still build mod_so by default) and a bit more performant. On the other hand it seems most of the world actually uses a dynamically linked httpd and the flexibility it provides during runtime. So isn't it time to switch to dynamic by default - if the platform supports it - and only build static on demand? 2) Which pre-cooked sets of modules to provide via configure? Currently the default set (no configure flags) is a mixture of minimal and some additional modules likely because their APACHE_MODULE m4 was copied. Then there is most, all and the possibility to enable or disable individual modules. I wonder whether some notion of most would be a better build default - but maybe not enabling the built modules by default. So there would be most (default), all and minimal. Before actually defining the according sets of modules, what do you think about the general direction? Rainer
Re: Module build defaults for trunk
On 3 Jun 2010, at 12:30, Rainer Jung wrote: Reading the feedback on the modules list I posted got me into thinking: 1) Should static module linking be still the default for httpd building? No. But we shouldn't change that within the 2.2.x line. 2) Which pre-cooked sets of modules to provide via configure? A question to which a satisfactory answer is elusive. But with dynamic linking we can sidestep the issue by building everything considered stable by default, and excluding only modules that are considered less-than mature. IMHO :) -- Nick Kew
Re: Module build defaults for trunk
On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung rainer.j...@kippdata.de wrote: Reading the feedback on the modules list I posted got me into thinking: 1) Should static module linking be still the default for httpd building? Of course the question is only relevant for platforms which allow dynamic linking and if we have APR_HAS_DSO. I know that static linking is expected to be more secure (but we still build mod_so by default) and a bit more performant. On the other hand it seems most of the world actually uses a dynamically linked httpd and the flexibility it provides during runtime. So isn't it time to switch to dynamic by default - if the platform supports it - and only build static on demand? +1 on dynamic by default when APR_HAS_DSO I wonder whether some notion of most would be a better build default - but maybe not enabling the built modules by default. So there would be most (default), all and minimal. +1 on default == most. (agree with Nick re: 2.2.x as ewll) -- Eric Covener cove...@gmail.com
Re: Module build defaults for trunk
On Thu, Jun 3, 2010 at 7:46 AM, Eric Covener cove...@gmail.com wrote: On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung rainer.j...@kippdata.de wrote: Reading the feedback on the modules list I posted got me into thinking: 1) Should static module linking be still the default for httpd building? Of course the question is only relevant for platforms which allow dynamic linking and if we have APR_HAS_DSO. I know that static linking is expected to be more secure (but we still build mod_so by default) and a bit more performant. On the other hand it seems most of the world actually uses a dynamically linked httpd and the flexibility it provides during runtime. So isn't it time to switch to dynamic by default - if the platform supports it - and only build static on demand? +1 on dynamic by default when APR_HAS_DSO I wonder whether some notion of most would be a better build default - but maybe not enabling the built modules by default. So there would be most (default), all and minimal. +1 on default == most. (agree with Nick re: 2.2.x as ewll) Here's a missing piece: A good generic httpd build has DSOs for all modules that could work on the system, but a nice httpd.conf loads only the modules that are necessary. Meanwhile, our module build system assumes that you wish to actively use the modules specified when you invoke configure. Different distros handle this in different ways, but the generic user who just wants to get past ./configure without doing anything stupid most likely ends up with many modules loaded which won't be used (extra security exposure, CPU, and memory).
Re: Module build defaults for trunk
On 03.06.2010 15:28, Jeff Trawick wrote: Here's a missing piece: A good generic httpd build has DSOs for all modules that could work on the system, but a nice httpd.conf loads only the modules that are necessary. Meanwhile, our module build system assumes that you wish to actively use the modules specified when you invoke configure. Different distros handle this in different ways, but the generic user who just wants to get past ./configure without doing anything stupid most likely ends up with many modules loaded which won't be used (extra security exposure, CPU, and memory). Right, that's the next topic, which modules to load by default and with which configuration. I hope we won't have to do to much work on the configuration topic (discussion might be hard like the ongoing deflate discussion shows), but instead will come to an easier conclusion about a core module set we want loaded by default. I expect most of those core modules already have an acceptable configuration in the current config. So after waiting a bit for more feedback on the general direction we can proceed with agreeing on a most list, a minimal list and which of those should be loaded by default. Rainer
Re: What's next for 2.2 and 2.3/trunk?
On Jun 2, 2010, at 8:40 PM, Sander Temme wrote: On Jun 1, 2010, at 9:08 AM, Jim Jagielski 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...? Amusingly (at least to me), I happened upon an old post by Joel Spolsky from 2002: http://www.joelonsoftware.com/articles/PickingShipDate.html For Systems With Millions of Customers and Millions of Integration Points, Prefer Rare Releases. You can do it like Apache: one release at the beginning of the Internet Bubble, and one release at the end. Perfect. I personally think we have enough to release for users to chew on: http://httpd.apache.org/docs/trunk/new_features_2_4.html PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD? That's a good question, but until we get a version of httpd 2.3/2.4/trunk out in people's hands with some confidence that what you are testing is pretty close to what it will be, API-wise, we'll never know. If I was just a module developer, I wouldn't be wasting my time following trunk either, due to our track record ;)
Re: Enhanced error log format for trunk?
On Tuesday 01 June 2010, Rainer Jung wrote: I repeatedly inserted millisecond or microsecond timestamps as well as PID and thread ID information into the ErrorLog when trying to diagnose problems, most often in combination with additional log lines. Due to the increased load and capability of systems and increasing amount of concurrency, would those features be interesting by default? Absolutely. Either by default of by some config directive. Having to recompile modules to get such information is a PITA. 4) General correlation improvements To be able to correlate error and access log, it would be helpful to share a common id, e.g. the unique_id, and be able to log it in both files. The id generated by mod_unique_id comes too late though (post_read_request). Since it actually only uses the request timestamp and the connection id of the request, it could be calculated much earlier. I have thought about this before, but I wanted to get the per-module loglevel configuration into trunk first. The log id could be created by the first call to ap_log_rerror. If there has not been an errorlog entry for a request by the time of the log transaction hook, the corresponding field in the access log would just be -. The function creating the log id could also log some interesting information once per request, instead of logging it for every log line. For example PID/TID, local+remote IP+Port, number of keep-alives on the connection, ... But I think a shorter id than the 20+ bytes of the unique id would be sufficient in most cases, and cause less disk space usage. I guess it would be good enough if the id is unique for one httpd instance in one day. Of course, if mod_unique_id is loaded, its long unique id could be used. Cheers, Stefan
Re: Module build defaults for trunk
On Jun 3, 2010, at 4:30 AM, Rainer Jung wrote: Reading the feedback on the modules list I posted got me into thinking: 1) Should static module linking be still the default for httpd building? +1 for dynamic build by default when APR_HAS_DSO. I don't buy the security argument: if you have sufficient privileges to replace DSO, you can also replace the web server itself. Of course folks should be able to keep building their modules static if they want to. How much autofoo is required for this and who will write it? This would be trunk, no changes to 2.2... give 'em a reason to upgrade. 2) Which pre-cooked sets of modules to provide via configure? minimal (the minimum needed to run and serve pages) default (a sane set likely to satisfy the majority of users) all (all that could reasonably be used in a deployment scenario) lint(every scrap of code in the tree) The lint option would be mostly of interest to developers who want to ensure that every module in the tree can be built and tested. If we build a module, we should turn it on (LoadModule). If the user doesn't want it turned on, they shouldn't build it. If a distributor wants to build a module and not turn it on by default, they can munge the configuration file (and many have done so). How much additional autofoo would be needed for this, and who will write it? Again, no changes to 2.2.x, trunk only. S. Currently the default set (no configure flags) is a mixture of minimal and some additional modules likely because their APACHE_MODULE m4 was copied. Then there is most, all and the possibility to enable or disable individual modules. I wonder whether some notion of most would be a better build default - but maybe not enabling the built modules by default. So there would be most (default), all and minimal. Before actually defining the according sets of modules, what do you think about the general direction? Rainer -- Sander Temme scte...@apache.org PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: What's next for 2.2 and 2.3/trunk?
On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote: PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD? That's a good question, but until we get a version of httpd 2.3/2.4/trunk out in people's hands with some confidence that what you are testing is pretty close to what it will be, API-wise, we'll never know. If I was just a module developer, I wouldn't be wasting my time following trunk either, due to our track record ;) Are we ready to freeze the API? I think that's our Alpha - Beta transition point. S. -- Sander Temme scte...@apache.org PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: Module build defaults for trunk
On 3 Jun 2010, at 14:59, Rainer Jung wrote: Right, that's the next topic, which modules to load by default and with which configuration. Yes, this is another important question. But I think it's helpful to separate them, because the issue of which modules are loaded can be delegated rather more flexibly - to run time as opposed to compile time. We could relatively easily provide a menu of potted configurations for different tasks. These then serve as startingpoints for the more elaborate bundles our downstream packagers love. In fact, that could itself become an httpd subproject. I suspect some of our non-coding docs folks might be interested. -- Nick Kew
Use cases for httpd?
Folks, Should we have a how do YOU use Apache checkpoint with our community to see how our users are actually deploying the server? I have a feeling many people just use their distro package, which means our discussions on what ./configure ... does has a different primary audience than we might think. We could launch an e-mail discussion, or setup a Survey Monkey (but keep it SHORT!!!) or something like that. Thoughts? S. -- Sander Temme scte...@apache.org PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: What's next for 2.2 and 2.3/trunk?
On 3 Jun 2010, at 15:59, Sander Temme wrote: Are we ready to freeze the API? I think that's our Alpha - Beta transition point. How about a chart or something documenting API differences since 2.2? That would seem a useful input to answering your question. If noone has such a beast sitting around, I can have a stab at something. -- Nick Kew
Re: Use cases for httpd?
On 3 Jun 2010, at 16:12, Sander Temme wrote: Should we have a how do YOU use Apache checkpoint with our community to see how our users are actually deploying the server? I have a feeling many people just use their distro package, which means our discussions on what ./configure ... does has a different primary audience than we might think. I have a feeling that won't really help with our defaults. Those who respond will be a self-selecting sample, and totally biased towards those admins who are capable of cooking their own configurations. We could launch an e-mail discussion, or setup a Survey Monkey (but keep it SHORT!!!) or something like that. A multiple-choice list of scenarios might tell us something. But perhaps better if it can grow organically, through a potted-configs subproject? -- Nick Kew
Re: What's next for 2.2 and 2.3/trunk?
On 6/3/2010 9:59 AM, Sander Temme wrote: On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote: PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD? That's a good question, but until we get a version of httpd 2.3/2.4/trunk out in people's hands with some confidence that what you are testing is pretty close to what it will be, API-wise, we'll never know. If I was just a module developer, I wouldn't be wasting my time following trunk either, due to our track record ;) Are we ready to freeze the API? I think that's our Alpha - Beta transition point. Freeze? Our versioning policy is and has been, n.odd == unstable, n.even == stable. Beta could have some extra encouragement to avoid changing the API. Perhaps chilled over ice? Extra assurances things are 'finished'? But users will probably react more strongly to '-beta' than they do to '-alpha', and will be more likely to participate if their favorite new feature didn't also become part of 2.2.
Re: What's next for 2.2 and 2.3/trunk?
On Jun 3, 2010, at 8:45 AM, William A. Rowe Jr. wrote: On 6/3/2010 9:59 AM, Sander Temme wrote: On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote: PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD? That's a good question, but until we get a version of httpd 2.3/2.4/trunk out in people's hands with some confidence that what you are testing is pretty close to what it will be, API-wise, we'll never know. If I was just a module developer, I wouldn't be wasting my time following trunk either, due to our track record ;) Are we ready to freeze the API? I think that's our Alpha - Beta transition point. Freeze? Our versioning policy is and has been, n.odd == unstable, n.even == stable. Yep, and now we're working on bringing 2.3/trunk towards 2.4/stable. Beta could have some extra encouragement to avoid changing the API. Perhaps chilled over ice? Code Slush, that's where it's at. Extra assurances things are 'finished'? But users will probably react more strongly to '-beta' than they do to '-alpha', and will be more likely to participate if their favorite new feature didn't also become part of 2.2. As Jim pointed out, third party module developers are unlikely to waste cycles until we indicate that we won't pull the rug out from under them API-wise. S. -- Sander Temme scte...@apache.org PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: Per-module / per-dir loglevel configuration version 4
On Wednesday 02 June 2010, Stefan Fritsch wrote:
I have updated my patch to the latest trunk and to use the variant
where the module for logging is selected with APLOG_USE_MODULE and
AP_DECLARE_MODULE macros:
APLOG_USE_MODULE(foo)
expands to
extern module AP_MODULE_DECLARE_DATA foo_module;
static int * const aplog_module_index =
(foo_module.module_index)
and
AP_DECLARE_MODULE(foo)
expands to
APLOG_USE_MODULE(foo);
module AP_MODULE_DECLARE_DATA foo_module
So, a single-file module only needs to do:
AP_DECLARE_MODULE(foo) =
{
STANDARD20_MODULE_STUFF,
...
Multi-file modules have to use APLOG_USE_MODULE in the other
files.
The patch is at
http://people.apache.org/~sf/per-module-loglevel-v4/ ,
I have added two additional patches (filenames 10*) to fix a segfault.
In addition, I now have this in http_log.h:
#define APLOG_NO_MODULE -1
static int * const aplog_module_index;
#define APLOG_MODULE_INDEX \
(aplog_module_index ? *aplog_module_index : APLOG_NO_MODULE)
This means, if some source file does not initialize aplog_module_index
with APLOG_USE_MODULE, logging will simply default to the global
loglevel. This works because static pointers are initialized to NULL
if no explicit initialization is given.
I think that's a nice solution. Modules from 2.2.x continue to work
without changes. But in order to benefit from per-module loglevel
configuration, they have to use the new macros.
Cheers,
Stefan
Re: What's next for 2.2 and 2.3/trunk?
On Thursday 03 June 2010, Sander Temme wrote: On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote: PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD? That's a good question, but until we get a version of httpd 2.3/2.4/trunk out in people's hands with some confidence that what you are testing is pretty close to what it will be, API-wise, we'll never know. If I was just a module developer, I wouldn't be wasting my time following trunk either, due to our track record ;) Are we ready to freeze the API? I think that's our Alpha - Beta transition point. I definitely want to have the per-module/per-dir loglevel config in 2.4. I think it's working well enough to be commited to trunk. We can work out the remaining issues there. Unless somebody disagrees, I am going to commit. Cheers, Stefan
Re: What's next for 2.2 and 2.3/trunk?
On 6/3/2010 11:58 AM, Stefan Fritsch wrote: I definitely want to have the per-module/per-dir loglevel config in 2.4. I think it's working well enough to be commited to trunk. We can work out the remaining issues there. Unless somebody disagrees, I am going to commit. I'm still uncomfortable with the new manditory per-every-source file macros. Not enough to vote against (more like -.05), if you are willing to find two more to +1 the proposed patch as it stands. Because it is VERY intrusive, commit-before review is inappropriate.
Re: What's next for 2.2 and 2.3/trunk?
On Thursday 03 June 2010, William A. Rowe Jr. wrote: On 6/3/2010 11:58 AM, Stefan Fritsch wrote: I definitely want to have the per-module/per-dir loglevel config in 2.4. I think it's working well enough to be commited to trunk. We can work out the remaining issues there. Unless somebody disagrees, I am going to commit. I'm still uncomfortable with the new manditory per-every-source file macros. Please look at my mail from 1 hour ago. With the latest change, the macros are no longer mandatory. Not using them will just lead to the default (i.e. not per-module) loglevel being used for that file. Not enough to vote against (more like -.05), if you are willing to find two more to +1 the proposed patch as it stands. Because it is VERY intrusive, commit-before review is inappropriate. On the one hand, I understand that. On the other hand, there seem to be very few people who have enough time to review the patch. It would be a pity if it was not included in 2.4 just for this reason. And quite a few people who I have spoken with at Wicklow have expressed interest in the functionality. How were such large changes handled in the past, like the AAA refactoring from 2.2 to 2.3?
Re: Per-module / per-dir loglevel configuration version 4
On Thu, Jun 3, 2010 at 12:49 PM, Stefan Fritsch s...@sfritsch.de wrote:
On Wednesday 02 June 2010, Stefan Fritsch wrote:
I have updated my patch to the latest trunk and to use the variant
where the module for logging is selected with APLOG_USE_MODULE and
AP_DECLARE_MODULE macros:
APLOG_USE_MODULE(foo)
expands to
extern module AP_MODULE_DECLARE_DATA foo_module;
static int * const aplog_module_index =
(foo_module.module_index)
and
AP_DECLARE_MODULE(foo)
expands to
APLOG_USE_MODULE(foo);
module AP_MODULE_DECLARE_DATA foo_module
So, a single-file module only needs to do:
AP_DECLARE_MODULE(foo) =
{
STANDARD20_MODULE_STUFF,
...
Multi-file modules have to use APLOG_USE_MODULE in the other
files.
The patch is at
http://people.apache.org/~sf/per-module-loglevel-v4/http://people.apache.org/%7Esf/per-module-loglevel-v4/,
I have added two additional patches (filenames 10*) to fix a segfault.
In addition, I now have this in http_log.h:
#define APLOG_NO_MODULE -1
static int * const aplog_module_index;
#define APLOG_MODULE_INDEX \
(aplog_module_index ? *aplog_module_index : APLOG_NO_MODULE)
This means, if some source file does not initialize aplog_module_index
with APLOG_USE_MODULE, logging will simply default to the global
loglevel. This works because static pointers are initialized to NULL
if no explicit initialization is given.
I think that's a nice solution. Modules from 2.2.x continue to work
without changes. But in order to benefit from per-module loglevel
configuration, they have to use the new macros.
sounds very reasonable to me
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 02.06.2010 18:23, Joe Orton wrote: Thanks very much for all the responses. There is strong consensus for retaining support for some varieties of 0.9.8 and possibly some 0.9.7. A new RFC, then, for trunk/2.3 and beyond: - support and build warning-free with OpenSSL = 0.9.8 - support and build with OpenSSL = 0.9.7a, albeit with (harmless) compiler warnings about argument const-ness all over the shop - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL (I have tried this out and it seems perfectly feasible.) Regards, Joe +1 Regards Rüdiger
Re: Per-module / per-dir loglevel configuration version 4
On 03.06.2010 20:09, Jeff Trawick wrote: On Thu, Jun 3, 2010 at 12:49 PM, Stefan Fritsch s...@sfritsch.de wrote: This means, if some source file does not initialize aplog_module_index with APLOG_USE_MODULE, logging will simply default to the global loglevel. This works because static pointers are initialized to NULL if no explicit initialization is given. I think that's a nice solution. Modules from 2.2.x continue to work without changes. But in order to benefit from per-module loglevel configuration, they have to use the new macros. sounds very reasonable to me +1 Regards Rüdiger
Re: What's next for 2.2 and 2.3/trunk?
On 6/3/2010 12:59 PM, Stefan Fritsch wrote: On Thursday 03 June 2010, William A. Rowe Jr. wrote: On 6/3/2010 11:58 AM, Stefan Fritsch wrote: I definitely want to have the per-module/per-dir loglevel config in 2.4. I think it's working well enough to be commited to trunk. We can work out the remaining issues there. Unless somebody disagrees, I am going to commit. I'm still uncomfortable with the new manditory per-every-source file macros. Please look at my mail from 1 hour ago. With the latest change, the macros are no longer mandatory. Not using them will just lead to the default (i.e. not per-module) loglevel being used for that file. Thanks! I'll review, this certainly sounds like it influences my own opinion. Not enough to vote against (more like -.05), if you are willing to find two more to +1 the proposed patch as it stands. Because it is VERY intrusive, commit-before review is inappropriate. On the one hand, I understand that. On the other hand, there seem to be very few people who have enough time to review the patch. It would be a pity if it was not included in 2.4 just for this reason. It would be, but it's necessary. The ASF is a collaborative environment; unreviewed code should not released, even when the authors are committers. A major patch like this hitting svn, without previous review, makes our fellow committers' eyes glaze over. If there is not positive feedback from two reviewers, this code does not belong in trunk/. As a committer, you are *free* to create your own sandboxes in svn to demonstrate code changes, if that helps attract the necessary review. How were such large changes handled in the past, like the AAA refactoring from 2.2 to 2.3? Not well [with respect to AAA, or LDAP specifically] - this is one of the concerns about 2.3 and the need for an extended review period, in spite of how many terrific changes sit on trunk.
Re: mod_deflate handling of empty initial brigade
Paul Fee wrote... Bryan McQuade wrote: Are there any cases where it's important for ap_pass_bridgade to pass on an empty brigade? Doesn't sound like it, but since this is a core library change I want to double check. When handling a CONNECT request, the response will have no body. In mod_proxy, the CONNECT handler currently skips most filters and writes via the connection filters. However there is a block of #if 0 code which intends to send only a FLUSH bucket down the filter chain. That's not quite the case of an entirely empty brigade, but it seems close enough to warrant highlighting. Thanks, Paul Can't think of anything else that might suffer from the sudden halt of passing empty brigades down the chain ( unless some 3rd party module using tandem-work filters is using them as 'place-markers' and actually EXPECTS them to show up at some point ) but there MIGHT be at least 2 other considerations... 1. If 'ap_pass_brigade()' becomes hard-wired to simply always return SUCCESS when it sees an empty brigade and it NEVER goes down the chain anymore... then is there ANY possibility this could become a 'lost brigade'? When would it ever get reused/released if it's not even making it down to the core filter set anymore? 2. It doesn't 'feel' right that 'ap_pass_brigade()' should always return SUCCESS when it starts throwing the empty brigades on the floor and does NOT send them down the chain. That seems 'misleading'. The call did NOT actually 'SUCCEED' because ap_pass_brigade() did NOT 'pass the brigade'. Should there be some other ERROR/WARNING level return code instead of always tossing back 'SUCCESS'? Might help with debugging later on or give module writers more options for writing their own 'safety catch' return code check(s) when calling ap_pass_brigade(). Yours Kevin Kiley
Re: Per-module / per-dir loglevel configuration version 4
On 02.06.2010 22:42, Stefan Fritsch wrote: I have updated my patch to the latest trunk and to use the variant where the module for logging is selected with APLOG_USE_MODULE and AP_DECLARE_MODULE macros: ... Multi-file modules have to use APLOG_USE_MODULE in the other files. The patch is at http://people.apache.org/~sf/per-module-loglevel-v4/ , both as one file and as a series split into more or less logical chunks. Comments are very welcome. Also, it would be nice if someone could try it with a different compiler than gcc. Some comments based on visual inspection. Next step (building/testing) is on my ToDo list. No major findings, only minor stuff. 0002-Introduce-log-levels-trace1-.-trace8.patch --- Minor: Use of LOG_PRIMASK and APLOG_LEVELMASK: LOG_PRIMASK usually comes from sys/syslog.h and we set it to 7 if it is not defined. Previously both masks were the same. Since this is no longer the case, I wouldn't -#defineAPLOG_LEVELMASK 7 /* mask off the level value */ +#define APLOG_LEVELMASK ((LOG_PRIMASK 1) + 1) /* mask off the level value */ but instead keep our mask at a fixed value: +#define APLOG_LEVELMASK 15 /* mask off the level value */ and then when using syslog -syslog(level_and_mask, %s, errstr); +syslog(level_and_mask APLOG_DEBUG ? level_and_mask : APLOG_DEBUG, + %s, errstr); instead +syslog(level_and_mask LOG_PRIMASK ? level_and_mask : APLOG_DEBUG, + %s, errstr); 0005-introduce-per-module-log-levels.patch -- ap_get_module_loglevel() and ap_set_module_loglevel() get the module index as an argument, but the doc says get at *their own* module-specific loglevel. It seems you can get/set the levels for all modules, not only your own. But well... If you change the wording, there's an anlogous comment in 0009-add-loglevel-to-request_rec-and-conn_rec.patch. Identation in the line: Setting LogLevel for all modules to %s, arg); (the line is also contained in 0010-Introcduce-per-dir-loglevel-configuration.patch, but unchanged there) Twice outdated code comments in log_error_core: * above the server log level. 0013-Adjust-loglevels-to-log-less-at-levels-INFO-and-DEBU.patch --- Indentation: proxy: HTTP: canonicalising URL %s, url); Indentation: loglevel = APLOG_INFO; Indentation in the new if block in server/protocol.c Indentation in modules/ssl/ssl_engine_kernel.c whenever ap_log_error is replaced by ap_log_cerror (argument indentation) 0017-associate-CONNECT-errors-with-the-request.patch Indentation in modules/proxy/mod_proxy.h whenever ap_log_error is replaced by ap_log_rerror (argument indentation) Additional remarks -- We need to fix and add some docs - removed directives for mod_ssl, mod_rewrite and mod_logio - new syntax for LogLevel - merging and inheritance of LogLevels between servers and modules Later possible improvement: should we add the module_name to the log line? Since you already know the index, associating the name would be easy. The question is, whether the info is important enough to add to the log line. Regards, Rainer
Re: Per-module / per-dir loglevel configuration version 4
On 6/3/2010 4:49 PM, Rainer Jung wrote: Indentation in modules/proxy/mod_proxy.h whenever ap_log_error is replaced by ap_log_rerror (argument indentation) Can we start pre-committing some of these pieces which are simply bug fixes, e.g. correcting the loglevel scope? It will save on review of the 'big picture' patch to get the small stuff out of the way, and into svn. Later possible improvement: should we add the module_name to the log line? Since you already know the index, associating the name would be easy. The question is, whether the info is important enough to add to the log line. The construct mod_foo: The foo module broke is just sooo common it would seem like a waste not to take advantage of the newfound intellegence in the error log, and reduce all this verbosity in the source code.
Re: Per-module / per-dir loglevel configuration version 4
On Thursday 03 June 2010, Rainer Jung wrote: The patch is at http://people.apache.org/~sf/per-module-loglevel-v4/ , both as one file and as a series split into more or less logical chunks. Comments are very welcome. Also, it would be nice if someone could try it with a different compiler than gcc. Some comments based on visual inspection. Next step (building/testing) is on my ToDo list. No major findings, only minor stuff. Thank you very much for the comments. They look very reasonable and I will integrate them in the next round of patches. Or should I create a branch in svn? But I think git is easier to use when tracking the changes in trunk. Additional remarks -- We need to fix and add some docs - removed directives for mod_ssl, mod_rewrite and mod_logio - new syntax for LogLevel I have started updating the docs today. Except for mod_ssl, these two points are done. I have put it as 2000_docs.patch into the directory above. - merging and inheritance of LogLevels between servers and modules This and the handling of per-dir, per-conn, and per-request loglevels is still missing. Also, there is infrastructure to use the loglevel from the conn_req, but no way to set it, yet. Maybe a LogLevelIfIP directive? Later possible improvement: should we add the module_name to the log line? Since you already know the index, associating the name would be easy. The question is, whether the info is important enough to add to the log line. It would be very useful when tuning the loglevel, but by default it may be too much noise. There are quite a few items in the same category (PID/TID, microseconds, ...) so a ErrorLogFlags or ErrorLogFormat directive may be a good idea. But these changes are not going to change the API/ABI, so IMHO they are less urgent. Cheers, Stefan
Re: Per-module / per-dir loglevel configuration version 4
On Friday 04 June 2010, William A. Rowe Jr. wrote: On 6/3/2010 4:49 PM, Rainer Jung wrote: Indentation in modules/proxy/mod_proxy.h whenever ap_log_error is replaced by ap_log_rerror (argument indentation) Can we start pre-committing some of these pieces which are simply bug fixes, e.g. correcting the loglevel scope? It will save on review of the 'big picture' patch to get the small stuff out of the way, and into svn. Sure. I have commited 0003-Introduce-SSLLOG_MARK-in-preparation-to-redefine-APL.patch 0004-move-find-module-logic-into-separate-function.patch 0012-Remove-loglevel-entry-in-core_dir_config-which-has-b.patch 0017-associate-CONNECT-errors-with-the-request.patch which are either pure bug fixes or pretty trivial. I will create a new patch series without these soon, hopefully tomorrow. Later possible improvement: should we add the module_name to the log line? Since you already know the index, associating the name would be easy. The question is, whether the info is important enough to add to the log line. The construct mod_foo: The foo module broke is just sooo common it would seem like a waste not to take advantage of the newfound intellegence in the error log, and reduce all this verbosity in the source code. Cheers, Stefan
Re: Per-module / per-dir loglevel configuration version 4
On Thu, Jun 3, 2010 at 7:27 PM, Stefan Fritsch s...@sfritsch.de wrote: which are either pure bug fixes or pretty trivial. I will create a new patch series without these soon, hopefully tomorrow. Appreciate your commitment to getting this in! -- Eric Covener cove...@gmail.com
Re: What's next for 2.2 and 2.3/trunk?
On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: It would be, but it's necessary. The ASF is a collaborative environment; unreviewed code should not released, even when the authors are committers. A major patch like this hitting svn, without previous review, makes our fellow committers' eyes glaze over. If there is not positive feedback from two reviewers, this code does not belong in trunk/. As a committer, you are *free* to create your own sandboxes in svn to demonstrate code changes, if that helps attract the necessary review. What you're describing here is review-then-commit (RTC). If we want trunk to be review-then-commit then we must make a decision and make it review-then-commit. If trunk is to remain commit-then- review (CTR), then people must be free to commit, then have people review. We cannot continue with this weird limbo situation where trunk is officially CTR, but unofficially RTC, because you have to check first on the list before committing anything, and you're too scared to commit anything because you're scared you're going to offend somebody who believes they should have been consulted first before someone commits to a CTR branch. The reason CTR is ideal for trunk is because the consequences of the rest of the project being too busy to review the code, is that the code is accepted without dispute. This produces a clear incentive to make sure that the rest of the project reviews code. It's really easy for the rest of the project to go I don't care about feature X, so I'll ignore reviewing that proposed code, I'm too busy. Under RTC, progress slows, people get fed up waiting for other people to review, progress stops, project dies. Having said that, RTC is entirely appropriate for the stable branch. Here the point is stability - we don't want progress, unless the progress is justified through the agreement of at least 3 other people. Progress slows, but progress doesn't stop, because the person writing the code can always wait until trunk becomes the next stable version. We've been doing this like this for over a decade, and it has worked really well. If you want the policy to be changed, argue that the policy should be changed. But do not try and apply a pseudo-policy on top of the already established ASF practice of CTR, it's not fair to our contributors. Regards, Graham --
Re: Per-module / per-dir loglevel configuration version 4
On Thu, Jun 3, 2010 at 7:51 PM, Eric Covener cove...@gmail.com wrote: On Thu, Jun 3, 2010 at 7:27 PM, Stefan Fritsch s...@sfritsch.de wrote: which are either pure bug fixes or pretty trivial. I will create a new patch series without these soon, hopefully tomorrow. Appreciate your commitment to getting this in! +1
Re: What's next for 2.2 and 2.3/trunk?
On Thu, Jun 3, 2010 at 7:51 PM, Graham Leggett minf...@sharp.fm wrote: On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: It would be, but it's necessary. The ASF is a collaborative environment; unreviewed code should not released, even when the authors are committers. A major patch like this hitting svn, without previous review, makes our fellow committers' eyes glaze over. If there is not positive feedback from two reviewers, this code does not belong in trunk/. As a committer, you are *free* to create your own sandboxes in svn to demonstrate code changes, if that helps attract the necessary review. What you're describing here is review-then-commit (RTC). If we want trunk to be review-then-commit then we must make a decision and make it review-then-commit. If trunk is to remain commit-then-review (CTR), then people must be free to commit, then have people review. We cannot continue with this weird limbo situation where trunk is officially CTR, but unofficially RTC, because you have to check first on the list before committing anything, and you're too scared to commit anything because you're scared you're going to offend somebody who believes they should have been consulted first before someone commits to a CTR branch. The reason CTR is ideal for trunk is because the consequences of the rest of the project being too busy to review the code, is that the code is accepted without dispute. This produces a clear incentive to make sure that the rest of the project reviews code. It's really easy for the rest of the project to go I don't care about feature X, so I'll ignore reviewing that proposed code, I'm too busy. Under RTC, progress slows, people get fed up waiting for other people to review, progress stops, project dies. Having said that, RTC is entirely appropriate for the stable branch. Here the point is stability - we don't want progress, unless the progress is justified through the agreement of at least 3 other people. Progress slows, but progress doesn't stop, because the person writing the code can always wait until trunk becomes the next stable version. We've been doing this like this for over a decade, and it has worked really well. If you want the policy to be changed, argue that the policy should be changed. But do not try and apply a pseudo-policy on top of the already established ASF practice of CTR, it's not fair to our contributors. +1 for the continued, and perhaps more widespread, voluntary soliciting of approval in advance for changes which add new modules or other significant new function, or make other widespread changes, or change prerequisites in a meaningful way, or have been discussed in the past without resolution (or with outright rejection), etc., etc. (We don't need an explicit laundry list, or any additional policy, to codify the practical matter that multiple developers need to be ready and willing to cope with such changes when they reach the user base). This has been done countless times by numerous people in this successful decade, in spite of, and even for the continued viability of, the C-T-R policy.
Re: What's next for 2.2 and 2.3/trunk?
On 6/3/2010 6:51 PM, Graham Leggett wrote: On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: It would be, but it's necessary. The ASF is a collaborative environment; unreviewed code should not released, even when the authors are committers. A major patch like this hitting svn, without previous review, makes our fellow committers' eyes glaze over. If there is not positive feedback from two reviewers, this code does not belong in trunk/. As a committer, you are *free* to create your own sandboxes in svn to demonstrate code changes, if that helps attract the necessary review. What you're describing here is review-then-commit (RTC). No, I wasn't. What I was suggesting is that code that is missing the 'then Commit' bits of RTC doesn't belong. It is not reassuring when committers aren't reviewing the patches offered when they are presented. Committing them to trunk doesn't reassure me that they'll have sufficient review after the commit, either. CTR is fine for all normal fixes. RTC is always preferred for major code refactorings. But the reviews need to happen, and this particular code has been available for discussion at dev@ for months, with very little comment between very few committers, which isn't a healthy sign.
Re: Per-module / per-dir loglevel configuration version 4
On 6/3/2010 7:10 PM, Jeff Trawick wrote: On Thu, Jun 3, 2010 at 7:51 PM, Eric Covener cove...@gmail.com mailto:cove...@gmail.com wrote: On Thu, Jun 3, 2010 at 7:27 PM, Stefan Fritsch s...@sfritsch.de mailto:s...@sfritsch.de wrote: which are either pure bug fixes or pretty trivial. I will create a new patch series without these soon, hopefully tomorrow. Appreciate your commitment to getting this in! +1 +1! - these improvements are going to go a long ways to let 'debug' logging become usable, instead of the current blight caused by mod_ssl and other modules guilty of the low S/N ratio.
Re: Per-module / per-dir loglevel configuration version 4
On 6/3/2010 11:49 AM, Stefan Fritsch wrote: I have added two additional patches (filenames 10*) to fix a segfault. In addition, I now have this in http_log.h: #define APLOG_NO_MODULE -1 static int * const aplog_module_index; #define APLOG_MODULE_INDEX \ (aplog_module_index ? *aplog_module_index : APLOG_NO_MODULE) This means, if some source file does not initialize aplog_module_index with APLOG_USE_MODULE, logging will simply default to the global loglevel. This works because static pointers are initialized to NULL if no explicit initialization is given. I think that's a nice solution. Modules from 2.2.x continue to work without changes. But in order to benefit from per-module loglevel configuration, they have to use the new macros. This seems to be a very good solution, and the fact that their are no constructor-time calls to initialize this should avoid any platform quirks. My only question is; are we assured to have the same module_index reassigned on each config/reload phase? The reason I'm worried is that this code won't refresh the index, but there may be platforms that don't actually do a module unload/reload/reinit heap of aplog_module_index to NULL.
Re: What's next for 2.2 and 2.3/trunk?
On 6/3/2010 10:13 AM, Nick Kew wrote: On 3 Jun 2010, at 15:59, Sander Temme wrote: Are we ready to freeze the API? I think that's our Alpha - Beta transition point. How about a chart or something documenting API differences since 2.2? That would seem a useful input to answering your question. +1 - and we need to worry about the user perspective, too, if we want folks to be looking at alphas and betas. If noone has such a beast sitting around, I can have a stab at something. There is this so far, which needs much love; http://httpd.apache.org/docs/trunk/upgrading.html http://httpd.apache.org/docs/trunk/new_features_2_4.html If nobody has interest in documenting the structural changes to the auth suite, with respect to nesting and block evaluation, I suggest we start to back out that code. It has complicated this release for years.
Re: What's next for 2.2 and 2.3/trunk?
On 6/1/2010 11:08 AM, Jim Jagielski 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...? I'd be strongly opposed to releasing all this refactoring of the proxy suite, etc, into the 2.2 tree. Not because of binary compatibility, but because users have certain expectations when they move from x.y.15 to x.y.16 that nothing much has changed, it's just lots of fixes. And if your backport ideas include a lot of config changes, well that further breaks the users expectations. To accomplish what you like, if we collectively believe trunk has stalled, would be to bump trunk to 2.5, and cross-pollinate a new 2.3 branch that can move forwards towards release. I'd like to see what can be accomplished with trunk over the next few weeks, and what agreements the project can come to, before we take such a radical step as branching two development lines. If bits of trunk that concern people can be sandboxed for the moment, instead, that might be less pain.
Re: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
On 04.06.2010 02:17, minf...@apache.org wrote:
Author: minfrin
Date: Fri Jun 4 00:17:16 2010
New Revision: 951222
URL: http://svn.apache.org/viewvc?rev=951222view=rev
Log:
mod_disk_cache: Decline the opportunity to cache if the response is
a 206 Partial Content. This stops a reverse proxied partial response
from becoming cached, and then being served in subsequent responses.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/cache/mod_disk_cache.c
Modified: httpd/httpd/trunk/CHANGES
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=951222r1=951221r2=951222view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Fri Jun 4 00:17:16 2010
@@ -28,6 +28,11 @@ Changes with Apache 2.3.6
processing is completed, avoiding orphaned callback pointers.
[Brett Gervasoni brettg senseofsecurity.com, Jeff Trawick]
+ *) mod_disk_cache: Decline the opportunity to cache if the response is
+ a 206 Partial Content. This stops a reverse proxied partial response
+ from becoming cached, and then being served in subsequent responses.
+ [Graham Leggett]
+
*) mod_deflate: avoid the risk of forwarding data before headers are set.
PR 49369 [Matthew Steele mdsteele google.com]
Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_disk_cache.c?rev=951222r1=951221r2=951222view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_disk_cache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_disk_cache.c Fri Jun 4 00:17:16 2010
@@ -333,6 +333,14 @@ static int create_entity(cache_handle_t
return DECLINED;
}
+/* we don't support caching of range requests (yet) */
+if (r-status == HTTP_PARTIAL_CONTENT) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ disk_cache: URL %s partial content response not
cached,
+ key);
+return DECLINED;
+}
+
Why is this needed? mod_cache itself does not allow partial content to be cached
and even if this does not work it should be fixed there and not in one of the
storage providers.
Regards
Rüdiger
Re: What's next for 2.2 and 2.3/trunk?
On 04.06.2010 01:51, Graham Leggett wrote: On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: It would be, but it's necessary. The ASF is a collaborative environment; unreviewed code should not released, even when the authors are committers. A major patch like this hitting svn, without previous review, makes our fellow committers' eyes glaze over. If there is not positive feedback from two reviewers, this code does not belong in trunk/. As a committer, you are *free* to create your own sandboxes in svn to demonstrate code changes, if that helps attract the necessary review. What you're describing here is review-then-commit (RTC). No. It was always the case that larger and more intrusive changes should be discussed on dev@ before folding it into trunk either by posting them or by creating a developer branch. This makes perfect sense to me as we are doing a collaborative effort in creating the code and it shows that there is enough support for these kind of changes. It helps avoiding a large back and forth in the trunk and -1 votes on commits. I don't think that we need any kind of written policy for this as I trust the developers here to do it if it is needed. Regards Rüdiger
