DO NOT REPLY [Bug 32915] New: - (snapshot 2.0.0.2002) Stopping apache causes error on stop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32915 Summary: (snapshot 2.0.0.2002) Stopping apache causes error on stop Product: Apache mod_aspdotnet Version: 2.0.0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: mod_aspdotnet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] http://httpd.apache.org/dev/dist/mod_aspdotnet-2.0.0.2002-snapshot-rev123880.msi This only happens with this snapshot version and not with the stable version. When stopping Apache, the following error pops up: Apache.exe - Application Error The instruction at 0x00c313b7 referenced memory at 0x00c313b7. The memory could not be read. Server: Apache/2.0.49 (Win32) PHP/4.3.10 DotNet Framework: 1.1.4322 OS: Win2000 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32021] - Document: Explicit choice of .NET framework version
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32021 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Allow Explicit choice of|Document: Explicit choice of |.NET framework version |.NET framework version --- Additional Comments From [EMAIL PROTECTED] 2005-01-03 07:17 --- httpd.conf examples; # to explicitly select the .NET 1.1 release; AspNetVersion v1.1.4322 # to explicitly seledt .NET 1.0 release; AspNetVersion v1.0.3705 still need to be documented -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
svn commit: r123945 - /httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp
Author: wrowe Date: Sun Jan 2 22:26:02 2005 New Revision: 123945 URL: http://svn.apache.org/viewcvs?view=revrev=123945 Log: It's not possible for the module to free it's own refcount, and we cannot be unloaded before process teardown. Let the mod_aspdotnet.so persist until Windows terminates the process. Modified: httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp Modified: httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp Url: http://svn.apache.org/viewcvs/httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp?view=diffrev=123945p1=httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cppr1=123944p2=httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cppr2=123945 == --- httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp (original) +++ httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp Sun Jan 2 22:26:02 2005 @@ -204,8 +204,11 @@ global_conf-pCorRuntime-Release(); } -if (global_conf-lock_module) -FreeLibrary(global_conf-lock_module); +// Although this module should remove itself, we end up in a broken +// state by unloading ourself underneath the running code. +// +// if (global_conf-lock_module) +//FreeLibrary(global_conf-lock_module); return APR_SUCCESS; }
DO NOT REPLY [Bug 32915] - (snapshot 2.0.0.2002) Stopping apache causes error on stop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32915 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-03 07:27 --- Fixed in svn commit 123945 - will be corrected in the next snapshot. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32658] - mod_aspdotnet returns stale cached files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32658 --- Additional Comments From [EMAIL PROTECTED] 2005-01-03 07:41 --- The logic to recover from a lost host context can be found in Apache.Web/HostFactory.h around line 270 onwards. I won't have time to fight with this in the next couple weeks, hopefully the timeout solution partially addresses this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
svn commit: r123947 - /httpd/mod_aspdotnet/trunk/STATUS.txt
Author: wrowe Date: Sun Jan 2 22:59:06 2005 New Revision: 123947 URL: http://svn.apache.org/viewcvs?view=revrev=123947 Log: Status was -way- out of date - refreshing it. Modified: httpd/mod_aspdotnet/trunk/STATUS.txt Modified: httpd/mod_aspdotnet/trunk/STATUS.txt Url: http://svn.apache.org/viewcvs/httpd/mod_aspdotnet/trunk/STATUS.txt?view=diffrev=123947p1=httpd/mod_aspdotnet/trunk/STATUS.txtr1=123946p2=httpd/mod_aspdotnet/trunk/STATUS.txtr2=123947 == --- httpd/mod_aspdotnet/trunk/STATUS.txt(original) +++ httpd/mod_aspdotnet/trunk/STATUS.txtSun Jan 2 22:59:06 2005 @@ -3,23 +3,30 @@ Release: -2.0.0 : tagged October 30, 2004 +2.0.0.2000 : released 20 Nov 2004 + RELEASE SHOWSTOPPERS: -* Vote to accept 2.0.0 for GA release -* Vote to accept the cli subproject for graduation -* Vote to accept the cli subproject mod_aspdotnet from httpd +CURRENT RELEASE NOTES: +* Fails to run on WIN32 (98, ME). WINNT (2k, XP, 2003) is required by + the ApplicationHost.CreateApplicationHost method, see .NET docs and + http://issues.apache.org/bugzilla/show_bug.cgi?id=32863 -CURRENT RELEASE NOTES: +* Does not recover gracefully after a System.Web.Host is lost, see + http://issues.apache.org/bugzilla/show_bug.cgi?id=32658 + +* Supports both Apache 2.0 or 2.1.3-dev (use Release 2.2/Debug 2.2 + project configurations with the APACHE22_PATH environment variable + pointing at the installed Apache 2.1/2.2 root) + +* Supports Microsoft's ASP.NET / .NET Runtime v1.1.4322 and v1.0.3705 + +* There are no test reports from .NET Runtime v2.0, as of yet -* Supports Microsoft's ASP.NET / .NET Runtime v1.1 and - Apache 2.0. This can be made more flexible for the user - to select an alternate runtime. Testing on Apache 2.1-dev - version should begin immediately after graduation. CURRENT VOTES:
svn commit: r123948 - /httpd/mod_aspdotnet/trunk/README.txt
Author: wrowe Date: Sun Jan 2 23:03:13 2005 New Revision: 123948 URL: http://svn.apache.org/viewcvs?view=revrev=123948 Log: A few new footnotes related to Apache 2.2 and Win32 compatibility. Modified: httpd/mod_aspdotnet/trunk/README.txt Modified: httpd/mod_aspdotnet/trunk/README.txt Url: http://svn.apache.org/viewcvs/httpd/mod_aspdotnet/trunk/README.txt?view=diffrev=123948p1=httpd/mod_aspdotnet/trunk/README.txtr1=123947p2=httpd/mod_aspdotnet/trunk/README.txtr2=123948 == --- httpd/mod_aspdotnet/trunk/README.txt(original) +++ httpd/mod_aspdotnet/trunk/README.txtSun Jan 2 23:03:13 2005 @@ -1,15 +1,23 @@ README for mod_aspdotnet + Apache.Web --- +mod_aspdotnet.so and Apache.Web.dll require Windows 2000 or later, they +are not compatible with Windows 98 or Windows ME. + Build Notes --- The top level workspace mod_aspdotnet.sln is invoked for a release build -with the syntax; +for Apache 2.0 with the syntax; - set APACHE_PATH=d:path\to\apache\serverroot + set APACHE_PATH=d:\path\to\apache2 devenv mod_aspdotnet.sln /useenv /build Release /project installer + +or to build for Apache 2.1-dev or Apache 2.2, invoke with the syntax; + + set APACHE22_PATH=d:\path\to\apache2.2 + devenv mod_aspdotnet.sln /useenv /build Release 2.2 /project installer The necessary files, mod_aspdotnet.so [+.pdb for debug symbols] and the Apache.Web.dll [+.pdb] are built into the installer.msi package at
DO NOT REPLY [Bug 32915] - (snapshot 2.0.0.2002) Stopping apache causes error on stop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32915 --- Additional Comments From [EMAIL PROTECTED] 2005-01-03 08:15 --- See the newest snapshot for corrections to this bug; http://httpd.apache.org/dev/dist/mod_aspdotnet-2.0.0.2002-snapshot-rev123949.msi -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32902] - Lowercase request headers not recognized by mod_aspdotnet apps.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32902. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32902 --- Additional Comments From [EMAIL PROTECTED] 2005-01-03 08:15 --- See the newest snapshot for corrections to this bug; http://httpd.apache.org/dev/dist/mod_aspdotnet-2.0.0.2002-snapshot-rev123949.msi -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: C-L or T-E: chunked for proxied request bodies
On Sat, 1 Jan 2005, Justin Erenkrantz wrote: Apache 1.3 does not support chunked request bodies. Eh - I am fairly sure it does (and has for quite a while) -except- for things whcih do not know their length - such as life output from CGI. (All 2.x GA releases do though.) So, that factors very much in the reason that I don't think we should send chunks by default: all requests Dw.
4GB File size limit
I need apache to serve up files greater than 4GB. Currently, even with large files enabled, it will not serve a file over 4GB on either windows or linux. When doing so, it shows the file size as being the original size mod 4GB. Ex: if the file is 4.2GB, when you go to download it, it says the file is 0.2GB. I've looked through the source and found that a 4 byte int is used for file offset stuff in many places, which would explain the behavior. The project I'm on desperately needs this functionality. I would like to know if the developers have this on their list of features to add in the near future? Thanks
Re: 4GB File size limit
On Mon, 03 Jan 2005 17:03:16 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I need apache to serve up files greater than 4GB. Currently, even with large files enabled, it will not serve a file over 4GB on either windows or linux. When doing so, it shows the file size as being the original size mod 4GB. Ex: if the file is 4.2GB, when you go to download it, it says the file is 0.2GB. APR 1.0, and thus Apache 2.1-dev, uses a 64-bit file offset on 32-bit Unix-ish platforms which implement the LFS standard. So the upcoming Apache 2.2 release will handle large files by default on modern Unix-ish platforms. I believe there is a way to build Apache 2.0.x to use 64-bit file offsets, but that isn't the default build.
Re: [1.3 PATCH] Select SSL version on ab command line
On Dec 21, 2004, at 1:03 PM, Sander Temme wrote:
On Dec 21, 2004, at 11:21 AM, William A. Rowe, Jr. wrote:
Can we use a separate flag to specific protocol version?
To address both your and André's response, yes we can. I even found an
unused letter that makes sense: -m for 'method'. And yes, I'll do a
2.1 patch. The reason my personal itch was with the 1.3 ab is that it
defaults to SSLv2 and my company's product doesn't support SSLv2.
Now that the holidays are over:
Tickle
If we (as a community) don't want to put that kind of work into ab,
especially 1.3 ab, I totally understand. In that case, I would like you
to consider the following one-line patch that just makes ab negotiate
the highest SSL version available rather than finding itself stuck at
the obsolete SSL version 2:
Index: src/support/ab.c
===
--- src/support/ab.c(revision 124022)
+++ src/support/ab.c(working copy)
@@ -1655,7 +1655,7 @@
#ifdef USE_SSL
SSL_library_init();
-if (!(ctx = SSL_CTX_new(SSLv2_client_method( {
+if (!(ctx = SSL_CTX_new(SSLv23_client_method( {
fprintf(stderr, Could not init SSL CTX: );
ERR_print_errors_fp(stderr);
exit(1);
Thanks!
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
Re: How to change ap_document_root variable from a apache2 module ?
This can be done quite safely in Apache1, by the way. I don't believe it can. Code? Well, since you don't need to worry about thread safety as long as you set it on every request, or reset it after each request you are fine. Something like: foo-old = ap_document_root(r); conf = ap_get_module_config(s-module_config, core_module); conf-ap_document_root = new; ap_register_cleanup(r-pool, foo, my_cleanup, ap_null_cleanup); Then set it back to foo-old in my_cleanup(). fwiw, we follow this exact logic in mod_perl for Apache 1.3 as well. And yes, I agree it is a hack to change anything in the core_module on a per-request basis, but there are a lot of things that are very useful hacks in Apache1 right. IIRC the inability to formally manipulate DocumentRoot is one of the things that prevents (or did prevent the last time I looked at it, which was a while ago) mod_vhost_alias and mod_frontpage from playing nice together. that I am hoping to see the richer and more flexible Apache2 API address. it would certainly be nice to do this, but there has always been a little pushback in the past IIRC. the main argument that I remember is the DocumentRoot is considered private to core one, but I'm just not sure how much I believe this - if it were really private we wouldn't offer read access either. does it make sense to perhaps code in an optional function (or somesuch) in 2.2 that core would use to override its own DocumentRoot on a per-request basis? --Geoff
Re: 4GB File size limit
On Mon, Jan 03, 2005 at 01:24:01PM -0500, Jeff Trawick wrote: I believe there is a way to build Apache 2.0.x to use 64-bit file offsets, but that isn't the default build. CFLAGS=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE and http://www.apache.org/~jorton/ap_splitlfs.diff has been working on ftp.heanet.ie (runs Linux) for ages and server 4Gb DVD ISO's without problem. Though, 2.1/2.2 is the way to go :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 4GB File size limit
i've tried CFLAGS=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE and it still doesn't work. i poked around on that ftp site and i couldn't find any files greater than 4GB. i found some that were 2GB, but none greater than 4. i would like to try a test download of a file that size. do you know of any? thanks On Mon, Jan 03, 2005 at 01:24:01PM -0500, Jeff Trawick wrote: I believe there is a way to build Apache 2.0.x to use 64-bit file offsets, but that isn't the default build. CFLAGS=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE and http://www.apache.org/~jorton/ap_splitlfs.diff has been working on ftp.heanet.ie (runs Linux) for ages and server 4Gb DVD ISO's without problem. Though, 2.1/2.2 is the way to go :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 4GB File size limit
On Mon, Jan 03, 2005 at 09:16:26PM +, [EMAIL PROTECTED] wrote: i've tried CFLAGS=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE and it still doesn't work. You need to apply the Joe Orton's patch aswell :) i poked around on that ftp site and i couldn't find any files greater than 4GB. i found some that were 2GB, but none greater than 4. i would like to try a test download of a file that size. do you know of any? http://ftp.heanet.ie/pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso 4.1Gb Recent curl versions (with Largefile support) are about the only reliable http clients I can find mind you. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 4GB File size limit
Hmmm, I wonder if the problem is the browser? I've tried downloading that file with Opera and IE and on both browsers, it says the file is 75,673,600 bytes, which is wrong. My largefile woes might be because of shortcomings in the browser, rather than in apache. On Mon, Jan 03, 2005 at 09:16:26PM +, [EMAIL PROTECTED] wrote: i've tried CFLAGS=-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE and it still doesn't work. You need to apply the Joe Orton's patch aswell :) i poked around on that ftp site and i couldn't find any files greater than 4GB. i found some that were 2GB, but none greater than 4. i would like to try a test download of a file that size. do you know of any? http://ftp.heanet.ie/pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso 4.1Gb Recent curl versions (with Largefile support) are about the only reliable http clients I can find mind you. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 4GB File size limit
[EMAIL PROTECTED] wrote: Hmmm, I wonder if the problem is the browser? I've tried downloading that file with Opera and IE and on both browsers, it says the file is 75,673,600 bytes, which is wrong. So does Firefox. However, Live HTTP Headers shows: GET /pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso HTTP/1.1 Host: ftp.heanet.ie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 200 OK Date: Mon, 03 Jan 2005 22:58:29 GMT Server: Apache/2.0.52 (Unix) Last-Modified: Thu, 20 May 2004 13:48:37 GMT Etag: 8b000d59-482b000-6e847740 Accept-Ranges: bytes Content-Length: 4370640896 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/octet-stream 4370640896 is 0x10482B000 and 75673600 is 0x482B000, so this is almost certainly a 32-bit integer overflow. Somebody should open an issue on the Mozilla bug tracker My largefile woes might be because of shortcomings in the browser, rather than in apache. Seems so. Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: 4GB File size limit
Julian Reschke wrote: 4370640896 is 0x10482B000 and 75673600 is 0x482B000, so this is almost certainly a 32-bit integer overflow. Somebody should open an issue on the Mozilla bug tracker https://bugzilla.mozilla.org/show_bug.cgi?id=276927 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
