Closing bugs.
Please do not mark bugs FIXED unless the problem is actually solved. I have noticed that bugs against experimental modules are often being closed with the explanation that the module isn't really ready for production use yet. That isn't a good reason to close a bug. The bug still exists, but people trying to fix the modules won't find the bug if it is marked FIXED. Bugs should only be marked FIXED if there is code or docs committed that actually resolved the problem. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Compiling Apache modules for windows
Hi Igor, > I'm interested in a third party module for Apache that I found in the > internet, but there's only the source code of it (a .c file), not the > .so file. I'm a windows user, and I read in the Apache website's faq if that's the module you found: http://pihl.kumpu.org/apache2/ then you can get a binary here: http://www.gknw.de/development/apache/httpd-2.0/win32/modules/mod_replace-0.3-2.0.43-w32.zip > that "only a limited number of the developers have the capability to > build the InstallShield package" for windows. Is building the .so very > complicated? What would I need? Is there a doc that explains it? http://httpd.apache.org/docs-2.0/platform/win_compiling.html Guenter.
Re: Compiling Apache modules for windows
Hi Igor, please send me the source or a link where I can find it; and I'll give it a try... in addition you can take a look on my site where you can find a bunch of other module binaries for Win32: http://www.gknw.de/development/apache/ Guenter. > I'm interested in a third party module for Apache that I found in the > internet, but there's only the source code of it (a .c file), not the > .so file. I'm a windows user, and I read in the Apache website's faq > that "only a limited number of the developers have the capability to > build the InstallShield package" for windows. Is building the .so very > complicated? What would I need? Is there a doc that explains it? If you > think it would be impossible for a newbie, is there a way for any of you > to compile the module for me? > By the way, I think the module is very interesting not only for me, > but for many people. It is called mod_replace, and it can make > replacements in the content of the pages served. I think this would be a > very useful feature for Apache. Maybe it can be included in the Apache > distribution in a near future, after the necessary testings, releases, > betas, etc.? > Thanks in advance, > Igor Leturia
Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"
Being off by a little is better than being off by the whole thing... My tests show that was Apache 1.3 behavior... At least that way the value is close, so if you're charging for bandwidth you're not overcharging so much, and you can still tell if the whole file got there or not. Dave - Original Message - From: "Bennett, Tony - CNF" <[EMAIL PROTECTED]> > I believe the %b gets its value from the request_rec's bytes_sent > member. This field is filled in by the content_length output > filter. It is not filled in during the actual send operation. > Even if it was filled in following each "send", that doesn't > mean it was received by the client... in the event of a disconnect, > I believe the bytes_sent will always be off. > > -tony
RE: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"
I believe the %b gets its value from the request_rec's bytes_sent member. This field is filled in by the content_length output filter. It is not filled in during the actual send operation. Even if it was filled in following each "send", that doesn't mean it was received by the client... in the event of a disconnect, I believe the bytes_sent will always be off. -tony -Original Message- From: David Burry [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 1:59 AM To: [EMAIL PROTECTED] Subject: Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested" ok serious problems still... I've sucessfully installed mod_logio (finally), and %O is STILL not logging the actual bytes transferred, but the bytes apache is INTENDING to eventually transfer... if I stop it in the middle by canceling or disconnecting, this number is horribly too big Of course it's a couple bytes larger than %b because of the headers included, but this is still totally useless for the purpose of figuring out if/when/whether the whole file was actually downloaded. Anyone have any ideas why this is so and how to fix it? Is the logging happening completely before the request is finished, could that be the problem? This should also be a concern for anyone who's using mod_logio to charge for bandwidth, because customers should be concerned about some serious overcharging going on here! I had to install libtool 1.4 and m4 1.4 and this was my configure line: ./configure --prefix=/usr/local/apache_2.0.43+logio --enable-logio --enable- usertrack --enable-file-cache --enable-cache --enable-mem-cache --enable-sta tic-support --disable-cgid --disable-cgi --enable-rewrite --with-mpm=worker --disable-userdir Dave - Original Message - From: "David Burry" <[EMAIL PROTECTED]> > Yes, I've been thinking of experimenting with mod_logio, but I'm a bit > hesitant to hack out a patch from (or use whole-hog) CVS HEAD into a > production site that gets 3 terabytes of traffic per day and I'm embarassed > to admit how much revenue depends on... ;o) Thanks for the link, I'll try > that. It won't be as accurate as getting the byte count without the > headers, but at least it should be something better than nothing if it works > as described... > > If we're not going to fix %s shouldn't we at least fix the documentation to > be more accurate? 2.0 and 1.3 really are quite different here. > > Dave > > - Original Message - > From: "Bojan Smojver" <[EMAIL PROTECTED]> > > Have you tried using mod_logio? If won't only give you the "body" bytes, > but > > also the "headers" bytes. It reports the number of input bytes too and > should > > understand encryption and compression. You can either check it out from > Apache > > CVS (HEAD), or download the patch for 2.0.43 here: > > http://www.rexursive.com/software.html. > > > > You'd use it with %I (for input) and %O (for output). It would be > interesting to > > know if it reports accurately in the case you described... >
Compiling Apache modules for windows
Hi! I'm interested in a third party module for Apache that I found in the internet, but there's only the source code of it (a .c file), not the .so file. I'm a windows user, and I read in the Apache website's faq that "only a limited number of the developers have the capability to build the InstallShield package" for windows. Is building the .so very complicated? What would I need? Is there a doc that explains it? If you think it would be impossible for a newbie, is there a way for any of you to compile the module for me? By the way, I think the module is very interesting not only for me, but for many people. It is called mod_replace, and it can make replacements in the content of the pages served. I think this would be a very useful feature for Apache. Maybe it can be included in the Apache distribution in a near future, after the necessary testings, releases, betas, etc.? Thanks in advance, Igor Leturia
Re: mod_proxy and Content-Length
[EMAIL PROTECTED] wrote: > Problems with 2.0.42 and mod_proxy with Content-Length: > > - 2.0.39 stripped C-L from all HTTP/1.0 responses. > - 2.0.40 retained C-L on HTTP/1.0 responses for GETs, but stripped it > for HEAD. > - 2.0.42 strips C-L from all HTTP/1.0 responses. > > Do people think that the 2.0.42 behaviour (stripping C-L from all > HTTP/1.0 responses) is correct? The messages referenced below would > suggest not, but .42 has reverted to .39's behaviour. I don't think proxy should touch content-length at all. If a filter fiddles with content length, then it should be responsible for removing the content-length header as needed so that it can be readded later. Proxy doesn't change content-length in itself - so it really has no business touching it. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..."
Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"
ok serious problems still... I've sucessfully installed mod_logio (finally), and %O is STILL not logging the actual bytes transferred, but the bytes apache is INTENDING to eventually transfer... if I stop it in the middle by canceling or disconnecting, this number is horribly too big Of course it's a couple bytes larger than %b because of the headers included, but this is still totally useless for the purpose of figuring out if/when/whether the whole file was actually downloaded. Anyone have any ideas why this is so and how to fix it? Is the logging happening completely before the request is finished, could that be the problem? This should also be a concern for anyone who's using mod_logio to charge for bandwidth, because customers should be concerned about some serious overcharging going on here! I had to install libtool 1.4 and m4 1.4 and this was my configure line: ./configure --prefix=/usr/local/apache_2.0.43+logio --enable-logio --enable- usertrack --enable-file-cache --enable-cache --enable-mem-cache --enable-sta tic-support --disable-cgid --disable-cgi --enable-rewrite --with-mpm=worker --disable-userdir Dave - Original Message - From: "David Burry" <[EMAIL PROTECTED]> > Yes, I've been thinking of experimenting with mod_logio, but I'm a bit > hesitant to hack out a patch from (or use whole-hog) CVS HEAD into a > production site that gets 3 terabytes of traffic per day and I'm embarassed > to admit how much revenue depends on... ;o) Thanks for the link, I'll try > that. It won't be as accurate as getting the byte count without the > headers, but at least it should be something better than nothing if it works > as described... > > If we're not going to fix %s shouldn't we at least fix the documentation to > be more accurate? 2.0 and 1.3 really are quite different here. > > Dave > > - Original Message - > From: "Bojan Smojver" <[EMAIL PROTECTED]> > > Have you tried using mod_logio? If won't only give you the "body" bytes, > but > > also the "headers" bytes. It reports the number of input bytes too and > should > > understand encryption and compression. You can either check it out from > Apache > > CVS (HEAD), or download the patch for 2.0.43 here: > > http://www.rexursive.com/software.html. > > > > You'd use it with %I (for input) and %O (for output). It would be > interesting to > > know if it reports accurately in the case you described... >
