Re: On topic serf/NetWare
Thanks, Norm! In the future, please send serf issues to serf-...@googlegroups.com (cc'd). We'll get this added before the next release. Cheers, -g On Mon, Mar 21, 2011 at 19:10, NormW wrote: > Hi all, > In serf src .\buckets\mmap_buckets.c : > > it needs something like : > >> @@ -16,6 +16,8 @@ >> #include >> #include >> >> +#if APR_HAS_MMAP >> + >> #include "serf.h" >> #include "serf_bucket_util.h" >> >> @@ -119,3 +121,6 @@ >> serf_default_restore_snapshot, >> serf_default_is_snapshot_set, >> }; >> + >> +#endif /* APR_HAS_MMAP */ >> + > > as not all (ahem) OS support mmap, as suggested by APR define. > > Regards, > Norm >
Re: Prior to apr 2.0 / httpd 2.4...
Greg, Am 22.03.2011 00:05, schrieb Greg Stein: I don't see how httpd GA is related to serf?? ... certainly, you want serf fixed up for a NetWare Subversion. But does httpd 2.4 consume libserf nowadays? (ie. one of the proxy modules?) yep: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_serf.c?view=log Gün.
On topic serf/NetWare
Hi all, In serf src .\buckets\mmap_buckets.c : it needs something like : @@ -16,6 +16,8 @@ #include #include +#if APR_HAS_MMAP + #include "serf.h" #include "serf_bucket_util.h" @@ -119,3 +121,6 @@ serf_default_restore_snapshot, serf_default_is_snapshot_set, }; + +#endif /* APR_HAS_MMAP */ + as not all (ahem) OS support mmap, as suggested by APR define. Regards, Norm
Fwd: Prior to apr 2.0 / httpd 2.4...
I saw "dev" and was thinking this was on dev@apr... but it was @httpd. Anyways... APR peeps: see below. -- Forwarded message -- From: Greg Stein Date: Mon, Mar 21, 2011 at 10:38 Subject: Re: Prior to apr 2.0 / httpd 2.4... To: dev@httpd.apache.org, "William A. Rowe Jr." On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wrote: > On 3/20/2011 7:43 PM, Dan Poirier wrote: >> On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr." >> wrote: >>> >>> [1] Note particularly that expat appears to be abandoned, no releases >>> in almost 4 yrs, with a significant security issue hanging over it we >>> patched in apr. No effort appears to be expended in providing any >>> alternate non-expat apr_xml interfaces. >> >> For APR to continue bundling expat seems easiest, in the absence of >> anyone motivated to do something more. > > I wish we had a better understanding of where expat is headed, or if it > is truly abandoned. It seems strange to rely on an orphaned dependency. > > Anyone have any inside knowledge or informed opinion? I'm a committer on Expat, but (as you've noted) the project has had no attention for quite a while. I wasn't aware of a security problem in there, however. Even if I dropped a new release of Expat, would we want to rely on the external build (and latest release being propagated) or continue to ship a patched Expat within APR? Switching to libxml2 would be possible (it is MIT licensed), but would require a lot more coding work in the xml support. Users of APR (1.x) also depend on Expat being available, and a switch would require them to rewrite their XML parsing code. Maybe that is acceptable for apps to switch to 2.0? In short: I can make a release happen, but would that matter to the APR project? Cheers, -g
Re: Prior to apr 2.0 / httpd 2.4...
On Mon, Mar 21, 2011 at 12:23, Guenter Knauf wrote:
> Greg,
> Am 21.03.2011 15:38, schrieb Greg Stein:
>...
>> I'm a committer on Expat, but (as you've noted) the project has had no
>> attention for quite a while. I wasn't aware of a security problem in
>> there, however.
>>
>> Even if I dropped a new release of Expat, would we want to rely on the
>> external build (and latest release being propagated) or continue to
>> ship a patched Expat within APR?
>>
>> Switching to libxml2 would be possible (it is MIT licensed), but would
>> require a lot more coding work in the xml support. Users of APR (1.x)
>> also depend on Expat being available, and a switch would require them
>> to rewrite their XML parsing code. Maybe that is acceptable for apps
>> to switch to 2.0?
>
> I followed up with libxml2 for a while on NetWare, and every now and then
> compilation was broken with next release due to not only fixing bugs but
> also adding a bunch of new features which then require futher tweaks (search
> for stubs which provide missing OS functions in network layer, etc).
> Further more many projects dont care about issues with compilers which dont
> like declarations after statements, and often you then end up with
> uncompilable code :-(
Yeah. In Subversion, we have a bunch of Windows developers, and they
call out when declarations occur after statements :-)
>> In short: I can make a release happen, but would that matter to the APR
>> project?
>
> when I tried to compile for Win32 with Watcom C I had to add this to expat:
> --- expat.h.orig Mon Nov 27 03:51:58 2006
> +++ expat.h Mon Aug 09 16:27:36 2010
> @@ -193,11 +193,19 @@
> XML_XmlDeclHandler xmldecl);
>
>
> +#if defined(WIN32) && defined(__WATCOMC__)
> +typedef struct {
> + void * __watcall (*malloc_fcn)(size_t size);
> + void * __watcall (*realloc_fcn)(void *ptr, size_t size);
> + void __watcall (*free_fcn)(void *ptr);
> +} XML_Memory_Handling_Suite;
> +#else
> typedef struct {
> void *(*malloc_fcn)(size_t size);
> void *(*realloc_fcn)(void *ptr, size_t size);
> void (*free_fcn)(void *ptr);
> } XML_Memory_Handling_Suite;
> +#endif
Seems reasonable. There have been a number of other little compilation
bug reports that have crept in over time. Could probably spend a day
just closing out those issues.
> /* Constructs a new parser; encoding is the encoding specified by the
> external protocol or NULL if there is none specified.
>
> BTW. is there a public repo from where oen can fetch current code?
http://sourceforge.net/scm/?type=cvs&group_id=10127
> oh, and while on things to fix where you are commiter:
> another one who plays with httpd and subversion on NetWare told me that
> current code of libserf has its quirks on NetWare - are you willing to take
> a look into that before we go for httpd GA?
I don't see how httpd GA is related to serf?? ... certainly, you want
serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
libserf nowadays? (ie. one of the proxy modules?)
> And where to post patches? To you directly?
serf-...@googlegroups.com
and/or open issues at code.google.com/p/serf/
Cheers,
-g
netware libserf quirks
On 3/21/2011 11:23 AM, Guenter Knauf wrote: > > BTW. is there a public repo from where oen can fetch current code? I presumed expat's home was http://sourceforge.net/projects/expat/ ... if it's not, I'd like to know :) > oh, and while on things to fix where you are commiter: > another one who plays with httpd and subversion on NetWare told me that > current code of > libserf has its quirks on NetWare - are you willing to take a look into that > before we go > for httpd GA? > And where to post patches? To you directly? About serf, http://code.google.com/p/serf/ - and there are a few others here on this list that are committers to serf.
Re: Adding ProxyErrorOverride support to mod_proxy_fcgi
On Mar 21, 2011, at 9:20 AM, Plüm, Rüdiger, VF-Group wrote: > > >> -Original Message- >> From: Jim Jagielski >> Sent: Montag, 21. März 2011 14:14 >> To: dev@httpd.apache.org >> Subject: Re: Adding ProxyErrorOverride support to mod_proxy_fcgi >> >> >> On Mar 18, 2011, at 6:03 PM, Mark Montague wrote: >> >>> I've created a patch to add support for the >> ProxyErrorOverride directive to mod_proxy_fcgi: >>> >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50913 >>> >>> Could someone review this patch, please, and get back to me >> with feedback and/or requests for changes? It's not >> important to me to have this functionality in 2.4, per se, >> but I'd like to address any concerns while everything is >> still relatively fresh in my mind. >>> >> >> iirc, this is also the case with mod_proxy_ajp... >> > > See https://issues.apache.org/bugzilla/show_bug.cgi?id=50945 :-). > *grin* I love when people provide patches!
Re: Prior to apr 2.0 / httpd 2.4...
Greg,
Am 21.03.2011 15:38, schrieb Greg Stein:
On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wrote:
On 3/20/2011 7:43 PM, Dan Poirier wrote:
On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr."
wrote:
[1] Note particularly that expat appears to be abandoned, no releases
in almost 4 yrs, with a significant security issue hanging over it we
patched in apr. No effort appears to be expended in providing any
alternate non-expat apr_xml interfaces.
For APR to continue bundling expat seems easiest, in the absence of
anyone motivated to do something more.
I wish we had a better understanding of where expat is headed, or if it
is truly abandoned. It seems strange to rely on an orphaned dependency.
Anyone have any inside knowledge or informed opinion?
I'm a committer on Expat, but (as you've noted) the project has had no
attention for quite a while. I wasn't aware of a security problem in
there, however.
Even if I dropped a new release of Expat, would we want to rely on the
external build (and latest release being propagated) or continue to
ship a patched Expat within APR?
Switching to libxml2 would be possible (it is MIT licensed), but would
require a lot more coding work in the xml support. Users of APR (1.x)
also depend on Expat being available, and a switch would require them
to rewrite their XML parsing code. Maybe that is acceptable for apps
to switch to 2.0?
I followed up with libxml2 for a while on NetWare, and every now and
then compilation was broken with next release due to not only fixing
bugs but also adding a bunch of new features which then require futher
tweaks (search for stubs which provide missing OS functions in network
layer, etc).
Further more many projects dont care about issues with compilers which
dont like declarations after statements, and often you then end up with
uncompilable code :-(
In short: I can make a release happen, but would that matter to the APR project?
when I tried to compile for Win32 with Watcom C I had to add this to expat:
--- expat.h.origMon Nov 27 03:51:58 2006
+++ expat.h Mon Aug 09 16:27:36 2010
@@ -193,11 +193,19 @@
XML_XmlDeclHandler xmldecl);
+#if defined(WIN32) && defined(__WATCOMC__)
+typedef struct {
+ void * __watcall (*malloc_fcn)(size_t size);
+ void * __watcall (*realloc_fcn)(void *ptr, size_t size);
+ void __watcall (*free_fcn)(void *ptr);
+} XML_Memory_Handling_Suite;
+#else
typedef struct {
void *(*malloc_fcn)(size_t size);
void *(*realloc_fcn)(void *ptr, size_t size);
void (*free_fcn)(void *ptr);
} XML_Memory_Handling_Suite;
+#endif
/* Constructs a new parser; encoding is the encoding specified by the
external protocol or NULL if there is none specified.
BTW. is there a public repo from where oen can fetch current code?
oh, and while on things to fix where you are commiter:
another one who plays with httpd and subversion on NetWare told me that
current code of libserf has its quirks on NetWare - are you willing to
take a look into that before we go for httpd GA?
And where to post patches? To you directly?
greets, Gün.
Re: where is dav_get_limit_xml_body?
On Sun, Mar 20, 2011 at 14:59, Guenter Knauf wrote: > Am 20.03.2011 19:41, schrieb William A. Rowe Jr.: >> >> Go ahead and simply remove it, just as the docs team would backport >> whatever >> documentation cleanup was appropriate without a STATUS dance. No code is >> actually harmed in this exercise. > > done: > http://svn.apache.org/viewvc?rev=1083536&view=rev Cool. Thanks for the (late) cleanup! :-P Cheers, -g
Re: Prior to apr 2.0 / httpd 2.4...
On 3/21/2011 3:20 AM, Nick Kew wrote: > > If I were to substitute libxml2 and demonstrate an expat-free version > of APR and HTTPD, would there be support for that? I'm thinking > the choice of native XML parser could become a compile-time or > even a run-time choice. I'd expect a quick&dirty prototype demo > to be just a couple of hours work. Absolutely; this seems like a topic for the apr list. It might alleviate any 'necessity' to start bundling the xml parser again , if either-or could be trivially consumed.
Re: Why is 1.3 still on the download page?
On 3/21/2011 5:30 AM, Vincent Bray wrote: > On 20 March 2011 20:23, William A. Rowe Jr. wrote: >> I've seen no objections, and count 3 +1's to remove these, so I'm cleaning >> this up today. > > Perhaps also someone would be kind enough to remove the weekly 1.3 > bugzilla summary? This had already been requested (before I even started website edits).
Re: Prior to apr 2.0 / httpd 2.4...
On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wrote: > On 3/20/2011 7:43 PM, Dan Poirier wrote: >> On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr." >> wrote: >>> >>> [1] Note particularly that expat appears to be abandoned, no releases >>> in almost 4 yrs, with a significant security issue hanging over it we >>> patched in apr. No effort appears to be expended in providing any >>> alternate non-expat apr_xml interfaces. >> >> For APR to continue bundling expat seems easiest, in the absence of >> anyone motivated to do something more. > > I wish we had a better understanding of where expat is headed, or if it > is truly abandoned. It seems strange to rely on an orphaned dependency. > > Anyone have any inside knowledge or informed opinion? I'm a committer on Expat, but (as you've noted) the project has had no attention for quite a while. I wasn't aware of a security problem in there, however. Even if I dropped a new release of Expat, would we want to rely on the external build (and latest release being propagated) or continue to ship a patched Expat within APR? Switching to libxml2 would be possible (it is MIT licensed), but would require a lot more coding work in the xml support. Users of APR (1.x) also depend on Expat being available, and a switch would require them to rewrite their XML parsing code. Maybe that is acceptable for apps to switch to 2.0? In short: I can make a release happen, but would that matter to the APR project? Cheers, -g
Re: Why is 1.3 still on the download page?
On Mon. 2011-03-21 at 06:55 AM EDT, "Malte S. Stretz" wrote: > On Monday 21 March 2011 11:30:26 Vincent Bray wrote: >> On 20 March 2011 20:23, William A. Rowe Jr. wrote: >> > I've seen no objections, and count 3 +1's to remove these, so I'm >> > cleaning this up today. >> >> Perhaps also someone would be kind enough to remove the weekly 1.3 >> bugzilla summary? > > There are currently still 63 bugs against v1.3 [1]. I'd wade through that > list, look at each bug and either > > (a) Close it as WONTFIX if the comments talk about v1.3.x only. > > (b) Change the product to httpd-2 if any comment states that it happens in > v2.x, too, adding a polite reminder to retest with a non-ancient version > if it wasn't updated for some time and maybe close it as NEEDINFO. > > Does anybody mind? +1, thanks for offering.
Re: Prior to apr 2.0 / httpd 2.4...
Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: Nobody has offered a reasonable response, let's try this again... the availability of pcre and expat are generally a both-or-neither proposition on most distributions. Ergo, any one of the following resolutions would restore logically consistency to the next-generation distribution... [x] apr 2.0 should resume bundling expat 2.0.1 fork[1] [ ] expat helpers should be dropped from apr 2.0, while httpd should assume an ap_ interface to expat with expat distributed with httpd-deps [ ] expat helpers should be dropped from apr 2.0, in favor of direct consumption of expat 2.x by httpd, with expat distributed with httpd-deps [ ] httpd will ship expat in srclib/apr/xml in spite of apr project decisions [ ] httpd-deps should drop pcre [ ] httpd-deps should be dropped Gün.
RE: Adding ProxyErrorOverride support to mod_proxy_fcgi
> -Original Message- > From: Jim Jagielski > Sent: Montag, 21. März 2011 14:14 > To: dev@httpd.apache.org > Subject: Re: Adding ProxyErrorOverride support to mod_proxy_fcgi > > > On Mar 18, 2011, at 6:03 PM, Mark Montague wrote: > > > I've created a patch to add support for the > ProxyErrorOverride directive to mod_proxy_fcgi: > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=50913 > > > > Could someone review this patch, please, and get back to me > with feedback and/or requests for changes? It's not > important to me to have this functionality in 2.4, per se, > but I'd like to address any concerns while everything is > still relatively fresh in my mind. > > > > iirc, this is also the case with mod_proxy_ajp... > See https://issues.apache.org/bugzilla/show_bug.cgi?id=50945 :-). Regards Rüdiger
Re: Adding ProxyErrorOverride support to mod_proxy_fcgi
On Mar 18, 2011, at 6:03 PM, Mark Montague wrote: > I've created a patch to add support for the ProxyErrorOverride directive to > mod_proxy_fcgi: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=50913 > > Could someone review this patch, please, and get back to me with feedback > and/or requests for changes? It's not important to me to have this > functionality in 2.4, per se, but I'd like to address any concerns while > everything is still relatively fresh in my mind. > iirc, this is also the case with mod_proxy_ajp... Will review the patch... Thx!
Re: httpd 2.4: mod_ratelimit
On Mar 21, 2011, at 8:39 AM, Reindl Harald wrote: > Hi > > http://httpd.apache.org/docs/trunk/mod/mod_ratelimit.html > > As i understand it is only planned to control the bandwith > per remote-address, but would it be possible to include > anything like "mod_bwshare" for a real rate-control > I would guess that mod_ratelimit, as it is used more and more often, will be the recipient of numerous feature enhancements...
httpd 2.4: mod_ratelimit
Hi http://httpd.apache.org/docs/trunk/mod/mod_ratelimit.html As i understand it is only planned to control the bandwith per remote-address, but would it be possible to include anything like "mod_bwshare" for a real rate-control http://www.topology.org/human/?a=/src/bwshare/README.html seems not really be maintained, but works well as long there are no H264-Videos, videos was the reason for us do disable mod_bwshare because something triggered the module :-( i really love the idea to configure httpd in a way that crazy people are stopped with a cheaper error-answer -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ signature.asc Description: OpenPGP digital signature
RE: Prior to apr 2.0 / httpd 2.4...
> -Original Message- > From: William A. Rowe Jr. > Sent: Montag, 21. März 2011 00:47 > To: dev@httpd.apache.org > Subject: Prior to apr 2.0 / httpd 2.4... > > Nobody has offered a reasonable response, let's try this again... the > availability of pcre and expat are generally a > both-or-neither proposition > on most distributions. Ergo, any one of the following > resolutions would > restore logically consistency to the next-generation distribution... > > [+1 ] apr 2.0 should resume bundling expat 2.0.1 fork[1] > [ ] expat helpers should be dropped from apr 2.0, > while httpd should assume an ap_ interface to expat > with expat distributed with httpd-deps > [ ] expat helpers should be dropped from apr 2.0, > in favor of direct consumption of expat 2.x by httpd, > with expat distributed with httpd-deps > [ ] httpd will ship expat in srclib/apr/xml > in spite of apr project decisions > [ ] httpd-deps should drop pcre > [ ] httpd-deps should be dropped > Regards Rüdiger
Re: Why is 1.3 still on the download page?
On Mon, Mar 21, 2011 at 7:06 AM, "Plüm, Rüdiger, VF-Group" wrote: > > >> -Original Message- >> From: Malte S. Stretz >> Sent: Montag, 21. März 2011 11:56 >> To: dev@httpd.apache.org >> Subject: Re: Why is 1.3 still on the download page? >> >> On Monday 21 March 2011 11:30:26 Vincent Bray wrote: >> > On 20 March 2011 20:23, William A. Rowe Jr. >> wrote: >> > > I've seen no objections, and count 3 +1's to remove these, so I'm >> > > cleaning this up today. >> > >> > Perhaps also someone would be kind enough to remove the weekly 1.3 >> > bugzilla summary? >> >> There are currently still 63 bugs against v1.3 [1]. I'd wade >> through that >> list, look at each bug and either >> >> (a) Close it as WONTFIX if the comments talk about v1.3.x only. >> >> (b) Change the product to httpd-2 if any comment states that >> it happens in >> v2.x, too, adding a polite reminder to retest with a >> non-ancient version >> if it wasn't updated for some time and maybe close it as NEEDINFO. >> >> Does anybody mind? > > IMHO go ahead with the above. +1
Re: Why is 1.3 still on the download page?
On Mon, Mar 21, 2011 at 6:37 AM, Nick Kew wrote: > > On 21 Mar 2011, at 10:30, Vincent Bray wrote: > >> On 20 March 2011 20:23, William A. Rowe Jr. wrote: >>> I've seen no objections, and count 3 +1's to remove these, so I'm cleaning >>> this up today. >> >> Perhaps also someone would be kind enough to remove the weekly 1.3 >> bugzilla summary? > > Does anyone look at those summaries? > > I sometimes catch a bug report from the mail it generates, but for an overview > I'll always use issues.apache.org. Weekly summaries are just an annoyance. +1 > I guess they might do some good as a nudge if bugs got assigned to > individuals! With paycheck too I presume ;)
Re: GA
On Mar 19, 2011, at 6:50 AM, Dan Poirier wrote: > On Fri. 2011-03-18 at 09:03 PM EDT, Nick Kew wrote: > >> On 19 Mar 2011, at 00:02, Dan Poirier wrote: >> >>> At some point, do we declare a feature-freeze for what will be 2.4.0? >> >> Features can be added during a release. > > I was just thinking of a temporary pause, that might be helpful in > getting to a point where trunk is stable enough to feel comfortable > declaring it 2.4.0. > > Maybe we don't need anything that formal. I get the sense that a few > people have things they'd like to get in before "2.4.0" for some reason, > but we hardly have a continuous stream of new features being added. > I think as we get closer to GA, most people will be more circumspect about changing the API willy-nilly... if it needs to be done, then it should be. 2.4 will be out there, as previous history clearly shows, for quite a Long Time, and we should ensure the API is what we need it to be.
Re: Prior to apr 2.0 / httpd 2.4...
On Mar 20, 2011, at 7:47 PM, William A. Rowe Jr. wrote: > Nobody has offered a reasonable response, let's try this again... the > availability of pcre and expat are generally a both-or-neither proposition > on most distributions. Ergo, any one of the following resolutions would > restore logically consistency to the next-generation distribution... > > [+1] apr 2.0 should resume bundling expat 2.0.1 fork[1]
Re: mod_fcgid in httpd tarball?
On Mar 18, 2011, at 6:07 PM, William A. Rowe Jr. wrote: > It seems like mod_fcgid has made huge progress and is now in a much > more stable bugfix epoch of it's life, similar to how mod_proxy had > progressed when development was kicked out of core for major http/1.1 > rework, and brought back in when a vast percentage of it's bugs had > been addressed. > > Do we want to introduce mod_fcgid now into httpd 2.3.x for the next beta? > I'd support that, yeah.
RE: Why is 1.3 still on the download page?
> -Original Message- > From: Malte S. Stretz > Sent: Montag, 21. März 2011 11:56 > To: dev@httpd.apache.org > Subject: Re: Why is 1.3 still on the download page? > > On Monday 21 March 2011 11:30:26 Vincent Bray wrote: > > On 20 March 2011 20:23, William A. Rowe Jr. > wrote: > > > I've seen no objections, and count 3 +1's to remove these, so I'm > > > cleaning this up today. > > > > Perhaps also someone would be kind enough to remove the weekly 1.3 > > bugzilla summary? > > There are currently still 63 bugs against v1.3 [1]. I'd wade > through that > list, look at each bug and either > > (a) Close it as WONTFIX if the comments talk about v1.3.x only. > > (b) Change the product to httpd-2 if any comment states that > it happens in > v2.x, too, adding a polite reminder to retest with a > non-ancient version > if it wasn't updated for some time and maybe close it as NEEDINFO. > > Does anybody mind? IMHO go ahead with the above. Regards Rüdiger
Re: Why is 1.3 still on the download page?
On Monday 21 March 2011 11:30:26 Vincent Bray wrote: > On 20 March 2011 20:23, William A. Rowe Jr. wrote: > > I've seen no objections, and count 3 +1's to remove these, so I'm > > cleaning this up today. > > Perhaps also someone would be kind enough to remove the weekly 1.3 > bugzilla summary? There are currently still 63 bugs against v1.3 [1]. I'd wade through that list, look at each bug and either (a) Close it as WONTFIX if the comments talk about v1.3.x only. (b) Change the product to httpd-2 if any comment states that it happens in v2.x, too, adding a polite reminder to retest with a non-ancient version if it wasn't updated for some time and maybe close it as NEEDINFO. Does anybody mind? Cheers, Malte [1]https://issues.apache.org/bugzilla/buglist.cgi?quicksearch=httpd-1.3
Re: Why is 1.3 still on the download page?
On 21 Mar 2011, at 10:30, Vincent Bray wrote: > On 20 March 2011 20:23, William A. Rowe Jr. wrote: >> I've seen no objections, and count 3 +1's to remove these, so I'm cleaning >> this up today. > > Perhaps also someone would be kind enough to remove the weekly 1.3 > bugzilla summary? Does anyone look at those summaries? I sometimes catch a bug report from the mail it generates, but for an overview I'll always use issues.apache.org. Weekly summaries are just an annoyance. I guess they might do some good as a nudge if bugs got assigned to individuals! -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: Why is 1.3 still on the download page?
On 20 March 2011 20:23, William A. Rowe Jr. wrote: > I've seen no objections, and count 3 +1's to remove these, so I'm cleaning > this up today. Perhaps also someone would be kind enough to remove the weekly 1.3 bugzilla summary? -- noodl
Re: Prior to apr 2.0 / httpd 2.4...
On 21 Mar 2011, at 01:13, William A. Rowe Jr. wrote: > I wish we had a better understanding of where expat is headed, or if it > is truly abandoned. It seems strange to rely on an orphaned dependency. I think we can be relaxed about it. We're one of many users, and our usage is hardly pushing the boundary. On the other hand, the reason we're not pushing the boundary is that to do so would be to re-invent the wheel. That is to say, applications interested in markup are introducing other libraries with more capabilities. Expat has proved too limiting. That raises the question: is there mileage in dropping expat and substituting libxml2? For our core usage, it's pretty-much a drop-in replacement, and it's the basis for a whole bunch of hitherto-separate applications like mod_proxy_html, mod_transform, mod_xml2 or mod_security. If I were to substitute libxml2 and demonstrate an expat-free version of APR and HTTPD, would there be support for that? I'm thinking the choice of native XML parser could become a compile-time or even a run-time choice. I'd expect a quick&dirty prototype demo to be just a couple of hours work. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
