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.
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.
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
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.
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.
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:
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
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.
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.
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
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
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
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
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 =
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
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
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
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
[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
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 --
20 matches
Mail list logo
