Re: Prior to apr 2.0 / httpd 2.4...
On 03/21/2011 12:47 AM, 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... [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 Simple majority, will re-offer this vote with the lowest vote getter dropped until we have consensus. Votes please? [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. The first option seems the least invasive at the moment. However since we have in many places the "provider" kind of API I see no reason why the same shouldn't be done for xml parsers and regular expressions. Think even httpd trunk has already some code that uses both regex and pcre. Regards -- ^TM
Re: Prior to apr 2.0 / httpd 2.4...
When will httpd-2.4 be released? 2011/3/21 William A. Rowe Jr. > On 3/20/2011 8:26 PM, Guenter Knauf wrote: > > Am 21.03.2011 01:29, schrieb William A. Rowe Jr.: > >> On 3/20/2011 7:10 PM, Guenter Knauf wrote: > >>> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: > [ ] httpd-deps should drop pcre > >>> huh? how can we drop it again? we have already with HEAD; > >>> better would be another point to select including it with the > httpd-deps tarball. > >> > >> It is brought into -deps, no? [Looks...] > > no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util, > nothing else. > > Sorry, I was being snarky towards myself, I realize that. > > So we were at "build zlib and openssl externally", now we are at "build > zlib, openssl, pcre and expat externally". The net is really not that > much of an issue (openssl is by far the most complex). >
Re: Prior to apr 2.0 / httpd 2.4...
On 3/20/2011 8:26 PM, Guenter Knauf wrote: > Am 21.03.2011 01:29, schrieb William A. Rowe Jr.: >> On 3/20/2011 7:10 PM, Guenter Knauf wrote: >>> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: [ ] httpd-deps should drop pcre >>> huh? how can we drop it again? we have already with HEAD; >>> better would be another point to select including it with the httpd-deps >>> tarball. >> >> It is brought into -deps, no? [Looks...] > no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util, > nothing else. Sorry, I was being snarky towards myself, I realize that. So we were at "build zlib and openssl externally", now we are at "build zlib, openssl, pcre and expat externally". The net is really not that much of an issue (openssl is by far the most complex).
Re: If there is a win32 2.4 build...
Am 21.03.2011 02:20, schrieb Guenter Knauf: Am 21.03.2011 02:12, schrieb William A. Rowe Jr.: dropping the compilation of mod_charset_lite - I believe no other modules would be affected by this change. not even that - I build it fine against OS shipping iconv on NetWare, and would like to keep it since it can solve some charset issues for autoindex ... whoops! not looked closely enough at the subject - k, if only for win32 then it depends on apr-iconv, yes ... G.
Re: If there is a win32 2.4 build...
On 3/20/2011 8:20 PM, Guenter Knauf wrote: > Am 21.03.2011 02:12, schrieb William A. Rowe Jr.: >> dropping the compilation of mod_charset_lite - I believe no other modules >> would be affected by this change. > not even that - I build it fine against OS shipping iconv on NetWare, and > would like to > keep it since it can solve some charset issues for autoindex ... And so you should. Also, if expat isn't a shipping component (or even if it is and you have some pull) take a look at the 2.0.1 patch I suggested. I'm strictly speaking of win32 with respect to apr returning 'we have no iconv, we have no xlate', other platforms should make that call based on feature tests, and for the vast majority, system iconv is fine.
Re: Prior to apr 2.0 / httpd 2.4...
Am 21.03.2011 01:29, schrieb William A. Rowe Jr.: On 3/20/2011 7:10 PM, Guenter Knauf wrote: Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: [ ] httpd-deps should drop pcre huh? how can we drop it again? we have already with HEAD; better would be another point to select including it with the httpd-deps tarball. It is brought into -deps, no? [Looks...] no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util, nothing else. G.
Re: If there is a win32 2.4 build...
Am 21.03.2011 02:12, schrieb William A. Rowe Jr.: dropping the compilation of mod_charset_lite - I believe no other modules would be affected by this change. not even that - I build it fine against OS shipping iconv on NetWare, and would like to keep it since it can solve some charset issues for autoindex ... Gün.
Re: Prior to apr 2.0 / httpd 2.4...
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?
If there is a win32 2.4 build...
It seems overdue to bump to expat 2.0.1. The attached seems to be the delta we (win and netware) likely care about to resolve significant defects in 2.0.1 (straight from their cvs tree, ignoring highly unusual platforms, and gratuitous whitespace changes). My inclination is to build for 2.4 using the 'stock' expat .dll of this plus 2.0.1 base distribution, irrespective of the sources shipped in srclib/apr-util/xml/expat since 1.95 is far from current. This is likely to make interop easier for anyone working with modern perl/python/php/etc. I would also jump up to openssl 1.0.0x (current), zlib 1.2.5 (although I detest its 64 bit off_t handling, which is a seperate discussion already started on another list) and drop apr_iconv altogether, which means also dropping the compilation of mod_charset_lite - I believe no other modules would be affected by this change. Comments? Index: lib/xmltok_impl.c === --- lib/xmltok_impl.c (.../2.0.1) (revision 6559) +++ lib/xmltok_impl.c (.../2.0.1-s2.1)(revision 6559) @@ -1744,7 +1744,7 @@ const char *end, POSITION *pos) { - while (ptr != end) { + while (ptr < end) { switch (BYTE_TYPE(enc, ptr)) { #define LEAD_CASE(n) \ case BT_LEAD ## n: \ Index: lib/xmlparse.c === --- lib/xmlparse.c (.../2.0.1) (revision 6559) +++ lib/xmlparse.c (.../2.0.1-s2.1)(revision 6559) @@ -1513,15 +1513,11 @@ : (char *)REALLOC(buffer, len * 2)); if (temp == NULL) { errorCode = XML_ERROR_NO_MEMORY; - return XML_STATUS_ERROR; -} -buffer = temp; -if (!buffer) { - errorCode = XML_ERROR_NO_MEMORY; eventPtr = eventEndPtr = NULL; processor = errorProcessor; return XML_STATUS_ERROR; } +buffer = temp; bufferLim = buffer + len * 2; } memcpy(buffer, end, nLeftOver); @@ -1672,6 +1668,8 @@ bufferPtr = buffer = newBuf; #endif /* not defined XML_CONTEXT_BYTES */ } +eventPtr = eventEndPtr = NULL; +positionPtr = NULL; } return bufferEnd; } @@ -3703,6 +3701,9 @@ return XML_ERROR_UNCLOSED_TOKEN; case XML_TOK_PARTIAL_CHAR: return XML_ERROR_PARTIAL_CHAR; + case -XML_TOK_PROLOG_S: +tok = -tok; +break; case XML_TOK_NONE: #ifdef XML_DTD /* for internal PE NOT referenced between declarations */ @@ -3782,15 +3783,17 @@ #endif /* XML_DTD */ dtd->hasParamEntityRefs = XML_TRUE; if (startDoctypeDeclHandler) { +XML_Char *pubId; if (!XmlIsPublicId(enc, s, next, eventPP)) return XML_ERROR_PUBLICID; -doctypePubid = poolStoreString(&tempPool, enc, - s + enc->minBytesPerChar, - next - enc->minBytesPerChar); -if (!doctypePubid) +pubId = poolStoreString(&tempPool, enc, +s + enc->minBytesPerChar, +next - enc->minBytesPerChar); +if (!pubId) return XML_ERROR_NO_MEMORY; -normalizePublicId((XML_Char *)doctypePubid); +normalizePublicId(pubId); poolFinish(&tempPool); +doctypePubid = pubId; handleDefault = XML_FALSE; goto alreadyChecked; } @@ -4947,7 +4950,7 @@ if (!entity->textPtr) { if (enc == encoding) eventPtr = ptr; - return XML_ERROR_ATTRIBUTE_EXTERNAL_ENTITY_REF; + return XML_ERROR_ATTRIBUTE_EXTERNAL_ENTITY_REF; } else { enum XML_Error result; @@ -6119,12 +6122,13 @@ } if (pool->blocks && pool->start == pool->blocks->s) { int blockSize = (int)(pool->end - pool->start)*2; -pool->blocks = (BLOCK *) +BLOCK *temp = (BLOCK *) pool->mem->realloc_fcn(pool->blocks, (offsetof(BLOCK, s) + blockSize * sizeof(XML_Char))); -if (pool->blocks == NULL) +if (temp == NULL) return XML_FALSE; +pool->blocks = temp; pool->blocks->size = blockSize; pool->ptr = pool->blocks->s + (pool->ptr - pool->start); pool->start = pool->blocks->s;
Re: Prior to apr 2.0 / httpd 2.4...
On Sun. 2011-03-20 at 07:47 PM EDT, "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... > > [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 > > Simple majority, will re-offer this vote with the lowest vote getter dropped > until we have consensus. Votes please? > > [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. Dan
Re: Prior to apr 2.0 / httpd 2.4...
On 3/20/2011 7:10 PM, Guenter Knauf wrote: > Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: >> [ ] httpd-deps should drop pcre > huh? how can we drop it again? we have already with HEAD; > better would be another point to select including it with the httpd-deps > tarball. It is brought into -deps, no? [Looks...] of course, the item above is our final resolution, I had looked for expat in the -deps package but hadn't thought to research pcre because I was under the impression that we had retained it. I'll go about disconnecting the win32 httpd-2.4 build from expat as well, so that the net effect is to rely on pre-installed expat and pcre packages. Thanks Gun, Bill
Re: Prior to apr 2.0 / httpd 2.4...
Am 21.03.2011 00:47, schrieb William A. Rowe Jr.: [ ] httpd-deps should drop pcre huh? how can we drop it again? we have already with HEAD; better would be another point to select including it with the httpd-deps tarball. Gün.
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... [ ] 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 Simple majority, will re-offer this vote with the lowest vote getter dropped until we have consensus. Votes please? [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.
Re: Why is 1.3 still on the download page?
On 2/10/2011 12:33 PM, William A. Rowe Jr. wrote: > On 2/10/2011 9:34 AM, Lars Eilebrecht wrote: >> Issac Goldstand wrote: >>> Am I getting senile, or didn't we vote on making 1.3 End-Of-Life >>> already? If so, why is 1.3.42 still featured on our download page as a >>> "current recommended release" a year later? Isn't it time to change >>> that to a note saying something to the extent of "If you absolutely MUST >>> continue using 1.3, you can download it from the archive?" >> >> Big +1. > > +1 here too - I proposed but the group decided to leave it there for a while. >> 1 year is more than a 'while' :) I've seen no objections, and count 3 +1's to remove these, so I'm cleaning this up today.
Re: where is dav_get_limit_xml_body?
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 Gün.
Re: where is dav_get_limit_xml_body?
On 3/20/2011 10:39 AM, Guenter Knauf wrote: > Am 20.03.2011 09:47, schrieb Guenter Knauf: >> I was just testing if I could automatically create an export list for >> mod_dav when I found this in mod_dav.h: >> >> /* >> ** >> ** MISCELLANEOUS STUFF >> */ >> >> /* fetch the "LimitXMLRequestBody" in force for this resource */ >> DAV_DECLARE(apr_size_t) dav_get_limit_xml_body(const request_rec *r); >> >> which source file should this function provide? I did search through the >> whole source tree, but couldnt find any other reference to this symbol ... >> (BTW. same is in 2.2.x branch too) > digged some deeper, and found this commit: > http://svn.apache.org/viewvc?view=revision&revision=85816 > to me it looks like it was just forgotten to remove the > dav_get_limit_xml_body() prototype > from mod_dav.h with this commit ... > if nobody objects I will remove it tommorow, and propose the backport. 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.
Re: where is dav_get_limit_xml_body?
Greg, Am 20.03.2011 17:50, schrieb Greg Stein: The function name is probably obsolete. I'm away from my laptop, so can't find the answer. Search the source for that Limit directive mentioned, and work out from there. I think I moved it out of mod_dav into a more generic location did that already - see also my 2nd post: http://svn.apache.org/viewvc?view=revision&revision=85816 seems that you just forgot to remove the dav_get_limit_xml_body() prototype from mod_dav.h with this commit ... do you agree that I remove it now? thanks, Gün.
Re: where is dav_get_limit_xml_body?
The function name is probably obsolete. I'm away from my laptop, so can't find the answer. Search the source for that Limit directive mentioned, and work out from there. I think I moved it out of mod_dav into a more generic location On Mar 20, 2011 8:47 AM, "Guenter Knauf" wrote: > I was just testing if I could automatically create an export list for > mod_dav when I found this in mod_dav.h: > > /* > ** > ** MISCELLANEOUS STUFF > */ > > /* fetch the "LimitXMLRequestBody" in force for this resource */ > DAV_DECLARE(apr_size_t) dav_get_limit_xml_body(const request_rec *r); > > which source file should this function provide? I did search through the > whole source tree, but couldnt find any other reference to this symbol ... > (BTW. same is in 2.2.x branch too) > > Gün. > >
Re: where is dav_get_limit_xml_body?
Am 20.03.2011 09:47, schrieb Guenter Knauf: I was just testing if I could automatically create an export list for mod_dav when I found this in mod_dav.h: /* ** ** MISCELLANEOUS STUFF */ /* fetch the "LimitXMLRequestBody" in force for this resource */ DAV_DECLARE(apr_size_t) dav_get_limit_xml_body(const request_rec *r); which source file should this function provide? I did search through the whole source tree, but couldnt find any other reference to this symbol ... (BTW. same is in 2.2.x branch too) digged some deeper, and found this commit: http://svn.apache.org/viewvc?view=revision&revision=85816 to me it looks like it was just forgotten to remove the dav_get_limit_xml_body() prototype from mod_dav.h with this commit ... if nobody objects I will remove it tommorow, and propose the backport. Gün.
Bug report for Apache httpd-1.3 [2011/03/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |14518|Opn|Reg|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l| |17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy | |19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build| |21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged | |21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files| |21975|Opn|Nor|2003-07-29|mod_rewrite RewriteMap from external program gets | |22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap| |25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co| |26126|New|Nor|2004-01-14|mod_include hangs with request body | |26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner| |26790|New|Maj|2004-02-09|error deleting old cache file | |29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,| |29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy | |30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe | |30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i| |30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections | |31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle| |32078|New|Enh|2004-11-05|clean up some compiler warnings | |32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE| |32974|Inf|Maj|2005-01-06|Client IP not set | |33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server| |33495|Inf|Cri|2005-02-10|Apache crashes with "WSADuplicateSocket failed for| |33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue| |33875|New|Enh|2005-03-07|Apache processes consuming CPU| |34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document| |34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout | |34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging vhost| |34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql| |35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI| |35439|New|Nor|2005-06-21|Problem with remove "/../" in util.c and mod_rewri| |35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie | |3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge| |36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file| |37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt| |37252|New|Reg|2005-10-26|gen_test_char reject NLS string | |38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (| |39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre| |40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?| |41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove| |42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code >= 600 | |43626|New|Maj|2007-10-15|r->path_info returning invalid value | |44768|New|Blk|2008-04-07|Server suddenly reverted to showing test page only| |44926|New|Nor|2008-05-02|1.3.41 binary downloads are faulty MSIs | |45083|New|Min|2008-05-27|CVE-2008-0005 not listed in vulnerabilities_13.htm| |45220|
Re: svn commit: r1082170 - /httpd/httpd/trunk/server/main.c
On Wednesday 16 March 2011, Dan Poirier wrote: > On Wed. 2011-03-16 at 11:53 AM EDT, jor...@apache.org wrote: > > Author: jorton > > Date: Wed Mar 16 15:53:34 2011 > > New Revision: 1082170 > > > > URL: http://svn.apache.org/viewvc?rev=1082170&view=rev > > Log: > > * server/main.c (main): Use the real null cleanup callback. > > Thanks Joe, I'd just spent the morning trying to figure out why no > CGI scripts were working (they seemed to crash shortly after the > fork) and this solved it. Sorry about that. I guess I should not make any last minute commits before going on vacation. Cheers, Stefan
where is dav_get_limit_xml_body?
I was just testing if I could automatically create an export list for mod_dav when I found this in mod_dav.h: /* ** ** MISCELLANEOUS STUFF */ /* fetch the "LimitXMLRequestBody" in force for this resource */ DAV_DECLARE(apr_size_t) dav_get_limit_xml_body(const request_rec *r); which source file should this function provide? I did search through the whole source tree, but couldnt find any other reference to this symbol ... (BTW. same is in 2.2.x branch too) Gün.