Re: mp2 and mp1
Philip M. Gollucci wrote: Hi, Are there any docs on getting A-T to place nice with a module that works under both mp1 and mp2.0.0+ ? The httpd.conf files written out load mod_perl.so instead of mod_perl2.so at the moment for me. Are you using Apache::TestMM or Apache::TestMB? When you run a test using Apache-Test and you don't specify the -apxs option during the 'perl Makefile.PL' or 'perl Build.PL' for your module, then Apache::Test will use the default one that it chose when it was built. So it looks like you built it initially against mp1. To test against mp2, just point it toward the right apxs perl Build.PL -apxs /usr/local/apache2/bin/apxs -- Michael Peters Developer Plus Three, LP
[PATCH[ feather.gif
Stop 'wget'ing the blasted feather.gif especially since wget doesn't exist by default on FreeBSD. snv diff feather.gif Makefile.am Index: feather.gif === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Property changes on: feather.gif ___ Name: svn:mime-type + application/octet-stream Index: Makefile.am === --- Makefile.am (revision 209929) +++ Makefile.am (working copy) @@ -76,7 +76,7 @@ docs/html/feather.gif: -mkdir docs -mkdir docs/html - (cd docs/html; wget http://httpd.apache.org/docs-2.0/images/feather.gif) + cp feather.gif docs/html docs/apu.tag: -mkdir docs -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
2.0.6-dev [docs preview]
If anyone wants to preview the docs for 2.0.6-dev, you can see them here: http://libapreq2.p6m7g8.net/ please use the offical site once 2.0.6-dev is released http://httpd.apache.org/apreq/docs/libapreq2/ END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: [VOTE] mod_ftp for HTTP Server Project
On Jul 7, 2005, at 11:26 AM, Jim Jagielski wrote: I therefore Call A Vote on whether we should support mod_ftp for inclusion into the Incubator and if we should accept mod_ftp upon graduation from the Incubator. +1 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: Please test 2.06-dev-rc1
Philip M. Gollucci wrote: Please test and report back. in cd glue/perl gmake test TEST_VERBOSE=1 TEST_FILES=t/apreq/request.t Just confirming that this fails under 5.8.7, 2.0.54 prefork, and mp 2.0.2-dev as well. -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com
Re: 1.3 and 2.0 releases?
On 7/8/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I know a few folks were expecting this note last Friday... here's the scoop. Jeff's patch to 2.0 was lovely. What's not lovely is that the chunked request processing has been hosed since at least 2.0.54. As much as I'd rather just commit his patch and release, there is a deeper problem going on that I'm investigating. Please post a reproduction case so that we can determine if this is a long-standing problem or a very recent regression. Much of the crowd isn't going to worry about shipping a new release which doesn't correct a long-standing problem. Until I can get 2.0 to serve all my test cases, it's somewhat pointless to push out a release. I am still up to the eyeballs with other stuff, and other people may be as well since there hasn't been a lot of help with your patches. Consider limiting your concern to regressions over the past couple of releases and publicized security issues and forget absolutely everything else, if it is important to get a release out within the week. Respectfully, Jeff
Re: [VOTE] mod_ftp for HTTP Server Project
Jeff Trawick wrote: On 7/7/05, Jim Jagielski [EMAIL PROTECTED] wrote: I therefore Call A Vote on whether we should support mod_ftp for inclusion into the Incubator and if we should accept mod_ftp upon graduation from the Incubator. +1 (not that you need any more votes) FTP can be crufty, but ftp clients are everywhere, and for that reason it is useful to provide ftp as a way to get at data without a hassle, particularly on random boxes where you don't want to worry if client software for more modern protocols is already installed/configured. I'm not an ASF member...and I'm not sure what in this message triggered this thought, but...for what its worth. I'm glad to see this work as well. Just to throw out another potential benefit down the road of this work. I could easily see this resulting in FTPS support finally being available in open source. Not that I'm a big fan of FTPS in general, but not having an FTPS server available in the open source world is something of a gap that probably should be filled. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
non-detaching httpd
Hi folks, I'd like to stop httpd from detaching itself, so I can start it from init. How can this be done ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: non-detaching httpd
Enrico Weigelt wrote: Hi folks, I'd like to stop httpd from detaching itself, so I can start it from init. How can this be done ? httpd -X if you want a single non-forking non-detached process httpd -F if you just want the main process to be non-detached and still have it fork off children -Rasmus
Re: [vote(s)] [Patch 1.3] Strict proxy C-L / T-E conformance
On Jul 8, 2005, at 10:45 PM, William A. Rowe, Jr. wrote: [22 hours - ping] Votes please? 2/3 of our users use 1.3, do you? Jim reminded me we don't ap_strtol everywhere, so the NULL check I guess remains a good idea, as would a (len_end == content_length) test which I will add before committing. I see: * content length is not known. We need to make 100% sure c-len is always * set correctly before we get here to correctly do keepalive. */ -ap_proxy_send_fb(f, r, c, c-len, 0, chunked, conf- io_buffer_size); +ap_proxy_send_fb(f, r, c, c-len, 0, (int)chunked, conf- io_buffer_size); } For some reason I'd feel safer with ap_proxy_send_fb(f, r, c, c-len, 0, (chunked ? 1 : 0), conf- io_buffer_size); Other than that nit, +1
Re: mod_mbox and i18n
Maxime Petazzoni wrote:
Hi,
Last week, we've been discussing what mod_mbox should output (XML+XSLT
or XHTML?) and we seemed to settle our minds on a simple XHTML output
for the interface, plus of course the XML backend for AJAX
sub-requests.
Still, someone on the #apache-modules IRC channel (was it chipig or
iholsman ? I don't remember) came up with some questions about
mod_mbox internationalization.
mod_mbox does not have a lot of strings ('prev', 'next', etc. Stuff
like that), but it actually does not contain any i18n mechanism (these
strings are hard coded in the C code).
We are here facing problems, whatever solution is used :
- If we choose XHTML output, strings of the interface will be
hard coded in the C code (in 'normal' / non-javascript browsing)
There's no reason the strings have to be hard coded into the C code.
You can pull them out into some sort of language specific file, just
like any other C program that worries about i18n.
Honestly, that seems like a far better solution to me. XML+XSLT seems
like extreme overkill if all you want is a way to have the strings
change on a per-language basis.
-garrett
Re: mod_mbox and i18n
There's no reason the strings have to be hard coded into the C code. You can pull them out into some sort of language specific file, just like any other C program that worries about i18n. This would mean more file I/O every time mod_mbox runs, and maybe using an external library such as gettext (quite heavy stuff for mod_mbox needs). Maybe some home-made system, but I fear that it won't be fast enough. Honestly, that seems like a far better solution to me. XML+XSLT seems like extreme overkill if all you want is a way to have the strings change on a per-language basis. I did not proposed XML+XSLT as a solution to i18n problems. It is just an interesting system that can provide both templating-like mechanism and i18n facilities (still, not as clean as I would like). - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: mod_mbox and i18n
Maxime Petazzoni wrote: There's no reason the strings have to be hard coded into the C code. You can pull them out into some sort of language specific file, just like any other C program that worries about i18n. This would mean more file I/O every time mod_mbox runs, and maybe using an external library such as gettext (quite heavy stuff for mod_mbox needs). Maybe some home-made system, but I fear that it won't be fast enough. ? Why not? You can cache the results per language in memory. Honestly, that seems like a far better solution to me. XML+XSLT seems like extreme overkill if all you want is a way to have the strings change on a per-language basis. I did not proposed XML+XSLT as a solution to i18n problems. It is just an interesting system that can provide both templating-like mechanism and i18n facilities (still, not as clean as I would like). Quoting from your previous mail: - With the XML+XSLT output, these strings are in the XSLT so they can be easily translated. Two sub-solutions are available : * provide a full XSLT per language Not maintainable if you ask me. Code duplication is something we want to avoid, and having to push xsl changes to n translations seems like a bad idea. * use variables for strings and a sub XSL defining this variables depending on the language. This is, at least in my mind, not going to be one bit faster than using (cached) gettext. FWIW, I'm not too worried about i18n and mod_mbox. It's only the interface changing language anyway. Sander
mp2 and mp1
Hi, Are there any docs on getting A-T to place nice with a module that works under both mp1 and mp2.0.0+ ? The httpd.conf files written out load mod_perl.so instead of mod_perl2.so at the moment for me. -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: mod_mbox and i18n
? Why not? You can cache the results per language in memory. I have to investigate on how to do this. Any pointers ? For the moment, I don't have enough Apache and APR knowledge not to see in a per-request mode. Not maintainable if you ask me. Code duplication is something we want to avoid, and having to push xsl changes to n translations seems like a bad idea. Absolutely. I know this, but I needed to present all solutions that came to me. FWIW, I'm not too worried about i18n and mod_mbox. It's only the interface changing language anyway. Of course, but if we want it, it would be nice to choose now an output format that will -later- comply to our i18n needs. I'm just trying to think about a not-that-far future. - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
