Re: "error 111" has been solved and some error occurred when configure apache
I have installed the mod_ssl openssl and apache successfully just according to the file "INSTALL" under the directory of mod_ssl. It's easy to understand and you can upgrate easily.:) But thank you all the same! --- Stas Bekman <[EMAIL PROTECTED]> 的正文： > Tom Schindl wrote: > > Well once more let mod_perl do everything for you, > see howto do that > > using INSTALL.simple.mod_ssl. > > or better, read the mp1 guide: > http://perl.apache.org/docs/1.0/guide/install.html#Installation_Scenarios_for_mod_perl_and_Other_Components > _ Do You Yahoo!? 美女明星应有尽有，"一搜"搜遍美图、艳图和酷图 http://image.yisou.com 100兆邮箱够不够用？雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/100m/*http://cn.promo.yahoo.com/minisite/100m/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
How to solve "Premature end of script headers?
Hi everyone! I have installed apache openssl and mod_ssl. Tha apache coule be started succesfuly and could run some simple CGI. But when I invoke a CGI, which is for check password for a portal, in a web it shows "Internal Server Error" and the error_log says "Premature end of script headers". Is it the problem of my program or some configure wrong? Thanks in advance! _ Do You Yahoo!? 美女明星应有尽有，"一搜"搜遍美图、艳图和酷图 http://image.yisou.com 100兆邮箱够不够用？雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/100m/*http://cn.promo.yahoo.com/minisite/100m/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to solve "Premature end of script headers?
YY Liu wrote: > Hi everyone! > I have installed apache openssl and mod_ssl. Tha > apache coule be started succesfuly and could run some > simple CGI. But when I invoke a CGI, which is for > check password for a portal, in a web it shows > "Internal Server Error" and the error_log says > "Premature end of script headers". > Is it the problem of my program or some configure > wrong? Most likely it's your program. That usually means that you have sent an output before doing: $r->send_httpd_header. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1] building mp1 with mod_ssl - what am I doing wrong?
Carl Brewer wrote: Stas Bekman wrote: Carl, can you build Apache w/o mod_perl w/ the rest of the things? Yes, it's just the mod_perl stuff that's barfing. It looks like the mod_perl make install isn't putting the header files into src/includes/. A quick google shows a bunch of relevant hits: http://www.google.ca/search?hl=en&ie=UTF-8&q=%22os.h%3A+No+such+file+or+directory%22&btnG=Search&meta= Also make sure that you are following the exact instructions from: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ The list of arguments I want to feed to the actual apache configure make this a bit of a pain, and I thought that it wasn't necessary to build httpd from within mod_perl (and indeed it shouldn't be anyway!). Not, unless you want a static build, which is what the quoted instructions do. But, at your suggestion, I've now done this, following the instructions on the site you referenced : cd openssl-0.9.7d ./config --prefix=/usr/local/openssl-0.9.7d make make test make install then in the mod_perl dir : perl Makefile.PL USE_APACI=1 EVERYTHING=1 DO_HTTPD=1 SSL_BASE=/usr/local/openssl-0.9.7d APACHE_PREFIX=/usr/local/apache-test APACHE_SRC=../apache_1.3.31/src APACI_ARGS='--enable-module=ssl,--enable-module=rewrite,--enable-module=proxy, --enable-module=so,--enable-module=access,--enable-module=auth, --enable-module=include,--enable-module=mime,--enable-module=log_config, --enable-module=alias,--enable-module=vhost_alias,--enable-module=log_agent, --enable-module=headers,--enable-shared=expires,--enable-shared=mime_magic, --enable-shared=ssl' And that compiled ok. Maybe the problem was this : "--activate-module=src/modules/perl/libperl.a" \ ? Right. In which case refer to the various sections in http://perl.apache.org/docs/1.0/guide/install.html that discuss the DSO build. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] registry tests problems (powerpc-aix-5.1.0.0 platform / IBM RS6000)
The core file actually have been created (although no 'Core dumped' message anywhere during tests). That's the backtrace from Modperl-Registry test: [quote] gdb /usr/local/apache2/bin/httpd -core t/core GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-ibm-aix5.1.0.0"... Core was generated by `httpd'. Program terminated with signal 11, Segmentation fault. #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955 955 mpm_common.c: No such file or directory. in mpm_common.c (gdb) bt #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955 #1 #2 0xd201ab70 in mpxs_Apache__RequestRec_content_type (r=???, type=???) at /home/bozy/src/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h:27 #3 0xd201b344 in XS_Apache__RequestRec_content_type (cv=0x204347d4) at RequestRec.xs:155 #4 0xd1ea2924 in Perl_pp_entersub () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so #5 0xd1f1b864 in Perl_runops_standard () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so #6 0xd1ee31e4 in S_call_body () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so #7 0xd1ee2e64 in Perl_call_sv () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so #8 0xd1f58ef8 in modperl_callback (handler=0x2032af48, p=0x20d55920, r=0x20d55958, s=0x20229130, args=0x2037acac) at modperl_callback.c:99 #9 0xd1f5988c in modperl_callback_run_handlers (idx=6, type=4, r=0x20d55958, c=0x0, s=0x20229130, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:268 #10 0xd1f59b94 in modperl_callback_per_dir (idx=6, r=0x20d55958, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:356 #11 0xd1f60fa0 in modperl_response_handler_run (r=0x20d55958, finish=0) at mod_perl.c:905 #12 0xd1f61318 in modperl_response_handler_cgi (r=0x20d55958) at mod_perl.c:1000 #13 0x1000aadc in ap_run_handler (r=0x20d55958) at config.c:151 #14 0x1000b640 in ap_invoke_handler (r=0x20d55958) at config.c:358 #15 0x1002c128 in ap_process_request (r=0x20d55958) at http_request.c:246 #16 0x10038b9c in ap_process_http_connection (c=0x20d4d9f0) at http_core.c:250 #17 0x100343cc in ap_run_process_connection (c=0x20d4d9f0) at connection.c:42 #18 0x1002e988 in child_main (child_num_arg=0) at prefork.c:609 #19 0x1002eb4c in make_child (s=0x0, slot=2) at prefork.c:703 #20 0x1002eeb0 in perform_idle_server_maintenance (p=0x0) at prefork.c:838 #21 0x1002f5e4 in ap_mpm_run (_pconf=0x20007868, plog=0x, s=0x0) at prefork.c:1039 #22 0x100012dc in main (argc=7, argv=0x2ff22964) at main.c:617 [unquote] Regards Alexey SB> Alexey Bozrikov wrote: SB> [taking the ModPerl-Registry branch of this multi-faced thread] >> Now, make test in ModPerl-Registry yields some error messages: SB> [...] >> t/404.t22 100.00% 1-2 >> t/bad_scripts.t11 100.00% 1 >> t/basic.t 181 5.56% 17 >> t/cgi.t21 50.00% 2 >> 2 tests skipped. >> Failed 4/14 test scripts, 71.43% okay. 5/70 subtests failed, 92.86% okay. >> [warning] server localhost:8529 shutdown >> [warning] port 8529 still in use... >> ...done >> [ error] error running tests (please examine t/logs/error_log) >> [unquote] >> >> The Apache error log contains following: >> >> [quote cat t/logs/error_log] >> [Fri Jul 30 08:55:15 2004] [notice] Apache/2.0.49 (Unix) >> mod_perl/1.99_15-dev Perl/v5.8.4 PHP/5.0.0 DAV/2 configured -- >> resuming normal operations >> [Fri Jul 30 08:55:15 2004] [info] Server built: Jul 15 2004 12:00:32 >> [Fri Jul 30 08:55:15 2004] [debug] prefork.c(955): AcceptMutex: sysvsem (default: >> sysvsem) >> >> *** The following error entry is expected and harmless *** >> [Fri Jul 30 08:55:55 2004] [error] >> /home/bozy/src/modperl-2.0/ModPerl-Registry/t/cgi-bin/cannot_be_found >> not found or unable to stat >> [Fri Jul 30 08:55:55 2004] [error] mpxs_Apache__RequestRec_print: >> $r->print can't be called before the response phase during global >> destruction.\n >> [Fri Jul 30 08:55:56 2004] [notice] child pid 16168 exit signal Segmentation fault >> (11) SB> You have a few segfaults reported. could you arrange for core files to SB> be allowed? Apache-Test is already doing that (ulimit -c unlimited), but SB> it doesn't seem to have an affect. Do you know why? SB> Once you get the core files, show us their backtraces. SB> http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults SB> Now while you are rebuilding things, please use the current modperl cvs, SB> so we will be in sync. Thanks. SB> http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution ** Nothi
[ANNOUNCE] Apache-AuthExpire-0.39
The uploaded file Apache-AuthExpire-0.39.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthExpire-0.39.tar.gz size: 7843 bytes md5: 2195ebc7ec82c8c11b8de4275584a49b No action is required on your part Request entered by: SPEEVES (Shannon Eric Peevey) Request entered on: Mon, 02 Aug 2004 11:24:14 GMT Request completed: Mon, 02 Aug 2004 11:24:58 GMT This was a heavy rewrite of the Apache-AuthExpire module. The changes include: 0.39 Thursday July 29, 2004 - bcw - Modified to account for proxy redirection that could result in the get_remote_host() fctn always returning 127.0.0.1. - bcw - I have modified the module to return DECLINED rather than OK. This allows other various authenTication schemes to operate. - bcw - Added a new configuration PerlSetVar variable "TimeoutPurge". This variable specifies the number of hours to wait before considering a timeout file to be too old to have come from the same session. This allows for someone to successfully use the AuthExpire to implement session timeouts and clean up old authentication timeout files after an extended period of time has elapsed. - speeves - updated my contact information and included Brandon's patches - fixed README and added up-to-date information - Added PerlSetVar variable 'AllowAlternateAuth' to allow for you to chain authenhandlers... - moved the dir_config variable declarations to the top of the handler subroutine and cleaned up the code that needed it in response to these changes - modified proxy patch to check for _any_ proxy server and return "real" client address - added PerlSetVar variable 'TimeFileDir' to allow you to specify an alternate location for your timeout files - added a lot of documentation with more information on each feature, as well as installation information. - changed the timeout file default directory to /logs/authexpire - updated the README to reflect the new changes. thanks, -- Shannon Eric Peevey President - EriKin Corporation [EMAIL PROTECTED] (940) 391-6777 http://www.erikin.com This message was sent using IMP, the Internet Messaging Program. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Perl : Darwin Macosx
Perl Framework 1.0.13 is out system Darwin 6.6 ppc or later , os x.2.8 or later Major A Version Perl 5.8.5 Thread-multi PerlMod 1.29, extensions : Standard, Net::Daemon, PlRPC, DBI, Apache::Test,Compress::Bzip2, Compress::Zlib, HTML::Parser, HTML::Tagset, HTTP::Daemon::SSL, IO::Socket::SSL, libwww, Net::SSLeay, URI, DBD::MySQL, GD2 Regards If someone wants to participate (the dev. of this framework) is welcome :) TODO for the next update --write a default mod_perl apache conf --write a default apache startup (mod_perl) /Library/Frameworks/Perl.framework/Libraries/PerlMod.ini --finish framework (intern) scripts -BEGIN PLUMBER CODE BLOCK- Version: 1.0 ¬ | | > Regards Plumber || GNU Darwin. ¬ \\\ plumber.gnu-darwin.org ¬ ¬ | | > OOP --\///\ (0)=(0) Darwin/Power Mac G4. ¬ | | > ( __ò ó__ ) The best for Fede ¬ \\\ federicafontana.it ¬ --END PLUMBER CODE BLOCK-- -BEGIN GEEK CODE BLOCK- Version: 3.1 GMU/S d+@ s: a- K+ PGP K dpu s--:-- C C-- B L X U P+++ C-- P! L--- E+++ W+++ P! L--- N+++ o-- K+ --END GEEK CODE BLOCK-- Plain, Loving, Useful, Mischievous, Brutal, Explosive, Responsible -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ERROR when compiled mod_perl with Apache assertion "rv == APR_SUC CESS" failed
Good Morning everybody, I need your help. I have installed APACHE2.0.50 with PHP4. I would like to work with ssl. To this, I am trying installed mod-perl1.99_14. When I compiled this, I have this message: [Mon Aug 02 09:02:02 2004] [crit] [Mon Aug 02 09:02:02 2004] file vhost.c, line 189, assertion "rv == APR_SUCCESS" failed . Please, what do Ido? Alexandre Salomé COMAU do Brasil Ind. e Com. Ltda - Analista de Sistemas - Engenharia - Divisão SystemRodovia Fernão Dias, Km 429 BR381 Distr. Industr. Paulo Camilo Pena - CEP 32536-000 Betim - MG - Brasil - Galpão 57 externo . cnpj: 02.693.750/0001-11 I.e: 067.80.00-22Tel: + 55-31-2123-6533 / Fax: + 55-31-2123-6523 http://www.comau.com.br <>-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
> But my point is, for a HEAD request, there is no data so apache should not > touch my content-length header. I really dislike to generate the full data > for the request and apache throws it away ( and even the I get no > Content-Length header ). for the record, this is fundamentally wrong. HEAD requests are supposed to be identical to GET requests in every way _except_ that there is no message body, which means that if a GET request for a specific resource does not have a C-L header then a HEAD request for the same resource also _must_ not have a C-L header. at least if you care about RFC compliance. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to solve "Premature end of script headers?
On Mon, 02 Aug 2004 00:30:22 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote: Yeah, what he said. There's really no way to know what it is based only on "Premature end of script headers", all that means is that something went wrong before it sent the header. Was there any other messages in the error log? Failing that... double check everything. > YY Liu wrote: > > Hi everyone! > > I have installed apache openssl and mod_ssl. Tha > > apache coule be started succesfuly and could run some > > simple CGI. But when I invoke a CGI, which is for > > check password for a portal, in a web it shows > > "Internal Server Error" and the error_log says > > "Premature end of script headers". > > Is it the problem of my program or some configure > > wrong? > > Most likely it's your program. That usually means that you have sent an > output before doing: $r->send_httpd_header. > > -- > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
CGI vs. mod_perl.
I'm rather new to mod_perl, so there's my disclaimer. When I learned perl CGI stuff, it was always done with CGI.pm. All the example scripts, etc, in the book were done that way. Sending headers, for example , was done like so: my $query = CGI->new(); print $query->header(); rather than the style of: $r->send_http_header(); Is this going to run more slowly, or is there much of a performance differance, or what differance does it make, exactly? The server is still running mod_perl, but will not take full advantage of the increased speed if I'm not using it's apache api (I intend to learn and start using it anyway, I'm just curious as to the question). -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: CGI vs. mod_perl.
Mike Ward wrote: > I'm rather new to mod_perl, so there's my disclaimer. > > When I learned perl CGI stuff, it was always done with CGI.pm. All the > example scripts, etc, in the book were done that way. Sending headers, > for example , was done like so: > > my $query = CGI->new(); > print $query->header(); > > rather than the style of: > > $r->send_http_header(); > > > Is this going to run more slowly, or is there much of a performance > differance, or what differance does it make, exactly? The server is > still running mod_perl, but will not take full advantage of the > increased speed if I'm not using it's apache api (I intend to learn > and start using it anyway, I'm just curious as to the question). ok, there are really three levels to CGI scripts when it comes to mod_perl. level 1 is standard CGI via mod_cgi (what you have probably done to date) level 2 is mod_perl via Apache::Registry. Apache::Registry is a mod_cgi emulator that allows you to take advantage of mod_perl's speed while still using legacy CGI tools - essentially allowing you move CGI unaltered scripts between mod_cgi and mod_perl for performance gain (for some definition of unaltered :) level 3 is using Apache::Registry as a way to dispatch scripts written using the mod_perl API, at which point you cannot move them back over to mod_cgi. outside of CGI scripting are mod_perl handlers (a fourth level), which use the mod_perl API at various points in the apache request lifecycle (including content generation). now, between level 2 and level 3 I'm not exactly sure what the performance gains would look like (and I don't think it's covered in http://www.chamas.com/bench/) , but it probably isn't significant enough to worry about as part of an initial migration step. I suspect that the real gains to be had in using the API are that you can drop things like the param parsing of CGI.pm in favor of tools like Apache::Request, but getting the initial boost from Apache::Registry might be all that you need, depending on the size of your application. HTH --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
AuthenNTLM and login
hi, i use authenNtlm on debian whith an Active directory. the module is ok (good job !) But some time the connection to AD is so slow, In those cases (no connection to AD aviable), i try to extract the login of the remote user. Do you know if it possible ? or if i absolute need AD active for that ? thank's Arnaud. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ERROR when compiled mod_perl with Apache assertion "rv == APR_SUC CESS" failed
SALOME Alexandre wrote: Good Morning everybody, I need your help. I have installed APACHE2.0.50 with PHP4. I would like to work with ssl. To this, I am trying installed mod-perl1.99_14. When I compiled this, I have this message: [Mon Aug 02 09:02:02 2004] [crit] [Mon Aug 02 09:02:02 2004] file vhost.c, line 189, assertion "rv == APR_SUCCESS" failed . Please, what do Ido? First you submit a proper problem report, as explained here: http://perl.apache.org/bugs/ Make sure to mention when do you get this error. and show us a small relevant config section which causes this error. Thanks. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] registry tests problems (powerpc-aix-5.1.0.0 platform / IBM RS6000)
Alexey Bozrikov wrote: The core file actually have been created (although no 'Core dumped' message anywhere during tests). That's the backtrace from Modperl-Registry test: [quote] gdb /usr/local/apache2/bin/httpd -core t/core GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-ibm-aix5.1.0.0"... Core was generated by `httpd'. Program terminated with signal 11, Segmentation fault. #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955 955 mpm_common.c: No such file or directory. in mpm_common.c (gdb) bt #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955 #1 #2 0xd201ab70 in mpxs_Apache__RequestRec_content_type (r=???, type=???) what does ??? means? is it a corrupted frame? why there is no address? Now, can you identify which test causes that? For example: cd ModPerl-Registry t/TEST -start t/TEST -run t/404.t t/TEST -run t/cgi.t etc... -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
Hi, Am Montag 02 August 2004 15:28 schrieb Geoffrey Young: > > But my point is, for a HEAD request, there is no data so apache should > > not touch my content-length header. I really dislike to generate the full > > data for the request and apache throws it away ( and even the I get no > > Content-Length header ). > > for the record, this is fundamentally wrong. HEAD requests are supposed to > be identical to GET requests in every way _except_ that there is no message > body, which means that if a GET request for a specific resource does not > have a C-L header then a HEAD request for the same resource also _must_ not > have a C-L header. at least if you care about RFC compliance. > ??? I do not know what you mean, my GET request _has_ a content-lenght header! For HEAD, I just do not calculate the expencive data for my body. I just missed the content-length header on HEAD requests that is delivered on GET. > --Geoff -- Boris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
Boris Zentner wrote: Hi, Am Montag 02 August 2004 15:28 schrieb Geoffrey Young: But my point is, for a HEAD request, there is no data so apache should not touch my content-length header. I really dislike to generate the full data for the request and apache throws it away ( and even the I get no Content-Length header ). for the record, this is fundamentally wrong. HEAD requests are supposed to be identical to GET requests in every way _except_ that there is no message body, which means that if a GET request for a specific resource does not have a C-L header then a HEAD request for the same resource also _must_ not have a C-L header. at least if you care about RFC compliance. ??? I do not know what you mean, my GET request _has_ a content-lenght header! For HEAD, I just do not calculate the expencive data for my body. I just missed the content-length header on HEAD requests that is delivered on GET. Geoff, see the t/apache/head_request.t test I've added last night. If you don't send a body, Apache strips the C-L header for HEAD requests. Sending at least 1 byte works as a workaround, but it smells like a bug in Apache. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
FW: mod_perl regex conundrum
I neglected to post this extension of our conversation to the mailing list, so at Stas' request, here it is. Thanks for your help with this issue. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 12:38 PM To: Simon Miner Subject: Re: mod_perl regex conundrum Hi Simon, > Thanks for your offer to examine our code. We were finally able to track > down the problem. Our code is using a third party API (which was also > upgraded), and that began emitting small pieces of Unicode, unbeknownst to > us. This Unicode was causing the regex slowdown. When we decoded the > Unicode, it began working as before. Great. Please follow up on the thread you've started on the modperl list and let others know what the problem was. Thank you. > I was hoping to meet you at the Open Source Conference last week to thank > you personally, but alas, I didn't see you. I really appreciate all the > help and insight you have offered as our team has researched this issue. > Also, thanks for your hard work on mod_perl. Thanks :) I was all over, didn't know it was hard to find me :) > Speaking of mod_perl, we are very interested in integrating mod_perl 2.0 > into our environment. However, it appears to still be in development. I > spoke with Randall Schwartz at the conference, and he estimates that > mod_perl 2 will be out of beta in about 6 months. I had the chance to It always amazes me how people who are completely uninvolved with the project take upon themselves the role of telling others what's going on in the project. We estimate that we will start releasing release candidates in a month or so. As soon as I finish working through the API and a few of the critical problems are resolved. > attend Sean Lynch's talk on managing the Ticket Master server farm (very > interesting stuff you guys are doing). I asked him if Ticket Master uses > mod_perl 2 yet, and he said no because he would like to see mod_perl 2 > support the MPM threading model. Hmm, here it is again. mp2 supports the MPM threading model for at least 3 years already. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp1]: different output under perlrun and CGI
Terr!
I got some differencies between using script under CGI and
Apache::PerlRun what i don't understand is that mandatory.
I am not an expert, so i try just to describe my situation.
I have an CGI-script with following sub:
sub PHeader {
$_[0]
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
I call this sub mostly &PHeader and only if i need "Content-type:
text/plain" i add a argument &PHeader(1), for example.
Under CGI it works fine, but under Apache::PerlRun has @_ a value (for
example "Apache::PerlRun=HASH(0x81ea01c) SCALAR(0x821a2bc)", i don't
know where and why it comes) and my PHeader does not understand that i
need a HTML-header. When i call a sub like &PHeader() or PHeader, it
works fine, so main program does not deliver any arguments.
Maybe it is something trivial but i had really confused why i got wrong
headers. When i ran it from command line, i got right header (like under
CGI).
Maybe someone can explain, why under PerlRun i got value for @_?
My system is Debian GNU/Linux Stable, Apache is 1.3.29, mod_perl 1.29,
perl 5.8.3.
example script:
#!/usr/bin/perl -w
use strict;
use CGI qw(:all);
our ($q, $char);
$q = new CGI;
$char = "iso-8859-15";
&PHeader;
# &PHeader() or PHeader works fine;
&PContent;
sub PHeader {
@_
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
sub PContent {
@_
? print "some plain text -> @_"
: print "some HTML-content";
}
Output of `perl -V`
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.4.25-ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.25-ti1211 #1 thu feb 19 18:20:12 est 2004
i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dpriv
lib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr
-Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/per
l5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.3
-Dsitearch=/usr/local/lib/perl/5.8.3 -Dman1dir=/usr/share/man
/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=
3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.3 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LA
RGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.3 (Debian 20040314)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.3
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 27 2004 16:21:10
@INC:
/etc/perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
--
TIA and with best regards
Kõike hääd,
Gunnar Koppel
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Call for help with mod_perl advocacy !
As some people might now, OSCon (http://conferences.oreillynet.com/os2004/) has just finished, and there was a mod_perl PR BOF were a bunch of mod_perl people gathered around and discussed mod_perl PR and advocacy. mod_perl is coming closer and closer to a 2.0 release (really soon now (tm)) and there was a lot of conversation about how we can insure that is comes out with a big bang! We all agreed that there were a lot of things that could be done to amplify the impact of mod_perl and increase our visibility and user base. Some of you might not have noticed, but take a look at the mod_perl usage statistics, and you'll notice that they don't look as good as they used to be. http://perl.apache.org/outstanding/stats/netcraft.html http://perl.apache.org/outstanding/stats/securityspace.html So, we decided to revive the [EMAIL PROTECTED] list, and use it as a focal point for all the future efforts in making mod_perl more widely known and used. So, if you are interested in helping out, or if you just want to know what is going on, please join us here : http://perl.apache.org/maillist/advocacy.html#Subscription_Information And you can get at the archive here : http://perl.apache.org/maillist/advocacy.html#Searchable_Archives Since there are no official minutes from the BOF, I'd encourage people that were there and had interesting ideas to repeat those ideas on the advocacy list in a little while (giving people time to subscribe to the list), and re-ignite discussion there. Another way to be helpfull, is to send out success stories. If your company is running mod_perl and loves it, get us the story. http://perl.apache.org/outstanding/sites.html http://perl.apache.org/outstanding/success_stories/index.html Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 signature.asc Description: OpenPGP digital signature
Re: mod_perl2, HEAD request and Content-Length
>> ??? I do not know what you mean, my GET request _has_ a content-lenght
>> header! For HEAD, I just do not calculate the expencive data for my body.
that is exactly what I mean - if you include a C-L header on a GET then you
are supposed to have one for a HEAD request as well, expensive or not. HEAD
is supposed to be exactly the same as a GET in all respects except that it
does not have a message body.
>>
>> I just missed the content-length header on HEAD requests that is
>> delivered on GET.
>
>
> Geoff, see the t/apache/head_request.t test I've added last night. If
> you don't send a body, Apache strips the C-L header for HEAD requests.
> Sending at least 1 byte works as a workaround, but it smells like a bug
> in Apache.
yes, clearly there is a bug in there, but not where you think - what is
important is that apache needs to do the same thing on GET as HEAD, not that
there is no C-L generated for contentless HEAD requests. this patch more
accurately represents the real bug which, IIRC, httpd is already aware of
(at least I'm recalling discussion about a C-L of 0).
--Geoff
Index: t/apache/head_request.t
===
RCS file: /home/cvs/modperl-2.0/t/apache/head_request.t,v
retrieving revision 1.2
diff -u -r1.2 head_request.t
--- t/apache/head_request.t 2 Aug 2004 03:38:30 - 1.2
+++ t/apache/head_request.t 2 Aug 2004 17:30:54 -
@@ -8,42 +8,54 @@
use Apache::TestUtil;
use Apache::TestRequest;
-plan tests => 12;
+plan tests => 12 * 2, todo => [2,5];
my $location = "/TestApache__head_request";
-{
-# if the response handler sends no data, and sets no C-L header,
-# the client doesn't get C-L header
-my $res = HEAD "$location";
-ok t_cmp $res->code, 200, "code";
-ok t_cmp $res->header('Content-Length'), undef, "C-L header";
-ok t_cmp $res->content, "", "content";
-}
-
-{
-# if the response handler sends no data, and sets C-L header,
-# the client doesn't get C-L header
-my $res = HEAD "$location?set_content_length";
-ok t_cmp $res->code, 200, "code";
-ok t_cmp $res->header('Content-Length'), undef, "C-L header";
-ok t_cmp $res->content, "", "content";
-}
-
-{
-# if the response handler sends data, and sets no C-L header,
-# the client doesn't get C-L header
-my $res = HEAD "$location?send_body";
-ok t_cmp $res->code, 200, "code";
-ok t_cmp $res->header('Content-Length'), undef, "C-L header";
-ok t_cmp $res->content, "", "content";
-}
-
-{
-# if the response handler sends data (e.g. one char string), and
-# sets C-L header, the client gets the C-L header
-my $res = HEAD "$location?send_body+set_content_length";
-ok t_cmp $res->code, 200, "code";
-ok t_cmp $res->header('Content-Length'), 25, "C-L header";
-ok t_cmp $res->content, "", "content";
+no strict qw(refs);
+foreach my $method qw(GET HEAD) {
+
+{
+# if the response handler sends no data, and sets no C-L header,
+# the client doesn't get C-L header
+my $uri = $location;
+my $res = $method->($uri);
+ok t_cmp $res->code, 200, "$method $uri code";
+ok t_cmp $res->header('Content-Length'), undef, "$method $uri C-L header";
+ok t_cmp $res->content, "", "$method $uri content";
+}
+
+{
+# if the response handler sends no data, and sets C-L header,
+# the client doesn't get C-L header
+my $uri = "$location?set_content_length";
+my $res = $method->($uri);
+ok t_cmp $res->code, 200, "$method $uri code";
+ok t_cmp $res->header('Content-Length'), undef, "$method $uri C-L header";
+ok t_cmp $res->content, "", "$method $uri content";
+}
+
+{
+# if the response handler sends data, and sets no C-L header,
+# the client doesn't get C-L header
+my $uri = "$location?send_body";
+my $res = $method->($uri);
+ok t_cmp $res->code, 200, "$method $uri code";
+ok t_cmp $res->header('Content-Length'), undef, "$method $uri C-L header";
+
+my $content = $method eq 'GET' ? 'This is a response string' : '';
+ok t_cmp $res->content, $content, "$method $uri content";
+}
+
+{
+# if the response handler sends data (e.g. one char string), and
+# sets C-L header, the client gets the C-L header
+my $uri = "$location?send_body+set_content_length";
+my $res = $method->($uri);
+ok t_cmp $res->code, 200, "$method $uri code";
+ok t_cmp $res->header('Content-Length'), 25, "$method $uri C-L header";
+
+my $content = $method eq 'GET' ? 'This is a response string' : '';
+ok t_cmp $res->content, $content, "$method $uri content";
+}
}
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
Geoffrey Young wrote: ??? I do not know what you mean, my GET request _has_ a content-lenght header! For HEAD, I just do not calculate the expencive data for my body. that is exactly what I mean - if you include a C-L header on a GET then you are supposed to have one for a HEAD request as well, expensive or not. HEAD is supposed to be exactly the same as a GET in all respects except that it does not have a message body. From RFC 2616: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request." From RFC 2119: "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." I think here we've hit a "valid reason in particular circumstance" to strip the content-length header. As for the implications, content-length is used for persistent HTTP connections but that doesn't happen for HEAD requests - only for GETs. Hence there should be no ill side effects by stripping the Content-Length metadata for HEAD requests. Cheers, Jean-Michel. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: FW: mod_perl regex conundrum
> "Simon" == Simon Miner <[EMAIL PROTECTED]> writes: >> Speaking of mod_perl, we are very interested in integrating mod_perl 2.0 >> into our environment. However, it appears to still be in development. I >> spoke with Randall Schwartz at the conference, and he estimates that >> mod_perl 2 will be out of beta in about 6 months. I had the chance to Simon> It always amazes me how people who are completely uninvolved with the Simon> project take upon themselves the role of telling others what's going on Simon> in the project. Simon> We estimate that we will start releasing release candidates in a month Simon> or so. As soon as I finish working through the API and a few of the Simon> critical problems are resolved. In my defense, I tried to indicate that this was merely a guess. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: apache::session::mysql: layout
On Sunday 01 August 2004 03:51 pm, Mark Copper wrote: > I created a table "sessions" in my db with columns "id" and "a_session" > per the Apache::Session::Store::MySQL pod, in particular, "a_session" is > of type text. > > Everything worked fine but I have a (rather silly) question: Why can't I > see the key/value pairs when I simply "select a_session from sessions" at > the mysql shell prompt? It should be serialized data. So binary stuff that isn't represented in standard chars in your client. -- -- Jayce^ pgpx5QzbZjO8r.pgp Description: signature
[ANNOUNCE] Travel Threads
I'd like to announce Travel Threads v1.0: http://www.travelthreads.com/ Travel Threads is a travelogue site build with Perl and HTML::Mason on mod_perl and Apache, using PosgreSQL as its database. Travel Threads lets you: - Post travel entries that can be self dated to when they were actually written (rather than automatically timestamped) - Set the country and city the entry is from - Add a map showing where the entry was written - Add photos either with the text, linked from the text, or as a commented slide show - Search other entries or photos by country, city or keywords Travel Threads is similar to a blog site except that its features are more geared towards travelers in its meta-data and presentation. The goal of this version is to gain enough users to generate the content needed for more interesting features. Travel Threads is free to use and read. All I ask is that users report all bugs, frustrations, ideas and questions! Garth Webb -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: FW: mod_perl regex conundrum
Randal L. Schwartz wrote: "Simon" == Simon Miner <[EMAIL PROTECTED]> writes: Speaking of mod_perl, we are very interested in integrating mod_perl 2.0 into our environment. However, it appears to still be in development. I spoke with Randall Schwartz at the conference, and he estimates that mod_perl 2 will be out of beta in about 6 months. I had the chance to Simon> It always amazes me how people who are completely uninvolved with the Simon> project take upon themselves the role of telling others what's going on Simon> in the project. Simon> We estimate that we will start releasing release candidates in a month Simon> or so. As soon as I finish working through the API and a few of the Simon> critical problems are resolved. In my defense, I tried to indicate that this was merely a guess. Well, let's try to make your guess wrong and get it out much sooner... like now? :) Seriously, you are more than welcome to help this happen sooner. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::Registry: Software caused connection abort
At 10:55 AM -0700 8/1/04, Stas Bekman wrote:
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 27 Jun 2004
21:26:45 - 1.50
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 1 Aug 2004
17:52:00 -
@@ -42,6 +42,7 @@
use File::Basename;
use Apache::Const -compile => qw(:common &OPT_EXECCGI);
+use APR::Const -compile => qw(ECONNABORTED);
use ModPerl::Const -compile => 'EXIT';
unless (defined $ModPerl::Registry::MarkLine) {
@@ -724,9 +725,14 @@
# ModPerl::Util::exit() throws an exception object whose rc is
# ModPerl::EXIT
# (see modperl_perl_exit() and modperl_errsv() C functions)
-if ($@ && !(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
-$self->log_error($@);
-return Apache::SERVER_ERROR;
+if ($@) {
+if ($@ == APR::ECONNABORTED) {
+# silently ignore client connection abort
+}
+elsif (!(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
+$self->log_error($@);
+return Apache::SERVER_ERROR;
+}
}
return Apache::OK;
}
Not quite--now I get this:
[Mon Aug 02 13:59:29 2004] [error] [client [ip address]] Argument
"Software caused connection abort at [script path]" isn't numeric in
numeric eq (==) at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/ModPerl/RegistryCooker.pm
line 723, line 20.\n, referer: [referring page]
I guess the problem is that, unlike $!, $@ doesn't have a numeric
component. I tried changing this to:
+if ($@) {
+if ($@ eq APR::ECONNABORTED) {
+# silently ignore client connection abort
but that didn't help. Now it says, "APR::Error: Can't handle 'eq' at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/APR/Error.pm line 39,
line 20.\n".
Next idea? :-)
--
Dan Wilga [EMAIL PROTECTED]
Web Technology Specialist http://www.mtholyoke.edu
Mount Holyoke CollegeTel: 413-538-3027
South Hadley, MA 01075"Who left the cake out in the rain?"
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
> From RFC 2616: > > "The HEAD method is identical to GET except that the server MUST NOT > return a message-body in the response. The metainformation contained in > the HTTP headers in response to a HEAD request SHOULD be identical to > the information sent in response to a GET request." indeed :) > > > From RFC 2119: > > "SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." yeah, this is the conversation that comes up all the time. from what I've seen in various forums, despite this definition SHOULD essentially means MUST. at least I haven't come across a circumstance where it hasn't :) > I think here we've hit a "valid reason in particular circumstance" to > strip the content-length header. well, that depends. but the short of it is that almost nobody is HEAD compliant (see a recent thread in the past month wrt mozilla and HEAD and yahoo). and almost nobody is compliant because almost nobody understands exactly what a HEAD request is supposed to entail, thus the reason why I was belaboring the point. but if you go against the RFC "recommendation" knowing full well what you are doing, I guess that's ok ;) > > As for the implications, content-length is used for persistent HTTP > connections but that doesn't happen for HEAD requests - only for GETs. > Hence there should be no ill side effects by stripping the > Content-Length metadata for HEAD requests. actually, I wonder how true that is. you would certainly think so, but if you go back to that mozilla thread and read through the bugzilla entries the mozilla dev guys make it sound as though they are using a HEAD request then making a series of GETs over the same connection. but what do I know... --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: mod_perl regex conundrum
Thanks for your offer to examine our code. We were finally able to track down the problem. Our code is using a third party API (which was also upgraded), and that began emitting small pieces of Unicode, unbeknownst to us. This Unicode was causing the regex slowdown. When we decoded the Unicode, it began working as before. Also, I talked to some folks at OSCON who said that some regex optimizations were removed in Perl 5.8 because they were buggy. This could also have contributed to the slowdown. Thanks again. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 1:29 PM To: Simon Miner Cc: mod_perl Mailing List ([EMAIL PROTECTED]) Subject: Re: mod_perl regex conundrum Simon Miner wrote: [...] > We found most of these approaches by looking in Practical mod_perl and the > mod_perl Developer's Cookbook. Are there any other suggestions that folks > on the mailing list can offer us as we continue to troubleshoot this issue? If you can pinpoint the chunks of code that you find slow, I can try to look at those to optimize them. e.g the regex that you've mentioned. It's usually possible to rewrite the regex to make it faster. If you can setup a self contained package with Benchmark.pm using Geoff's Apache-Test skeleton (http://apache.org/~geoff/) -- that will save me a lot of time trying to reproduce the environment. Though I'm working on linux, but hopefully it shouldn't make much difference. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
Geoffrey Young wrote:
[...]
I just missed the content-length header on HEAD requests that is
delivered on GET.
Geoff, see the t/apache/head_request.t test I've added last night. If
you don't send a body, Apache strips the C-L header for HEAD requests.
Sending at least 1 byte works as a workaround, but it smells like a bug
in Apache.
yes, clearly there is a bug in there, but not where you think - what is
important is that apache needs to do the same thing on GET as HEAD, not that
there is no C-L generated for contentless HEAD requests. this patch more
accurately represents the real bug which, IIRC, httpd is already aware of
(at least I'm recalling discussion about a C-L of 0).
Why do you say so? Your patch respresents a related, but a different
issue. Boris has a problem with HEAD, and that's what the test was testing.
But, certainly please commit it, rename the files to something different
(content_length_header.t?) since it's not longer a HEAD request. And
please add a comment explaining the bug, ideally with xref to a bugzilla
for the bug you are talking about or discussion thread.
Thanks.
also please move that no strict thing, inside the block, where it is
needed. Thanks.
+no strict qw(refs);
+foreach my $method qw(GET HEAD) {
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::Registry: Software caused connection abort
Dan Wilga wrote:
At 10:55 AM -0700 8/1/04, Stas Bekman wrote:
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm27 Jun 2004
21:26:45 -1.50
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm1 Aug 2004
17:52:00 -
@@ -42,6 +42,7 @@
use File::Basename;
use Apache::Const -compile => qw(:common &OPT_EXECCGI);
+use APR::Const -compile => qw(ECONNABORTED);
use ModPerl::Const -compile => 'EXIT';
unless (defined $ModPerl::Registry::MarkLine) {
@@ -724,9 +725,14 @@
# ModPerl::Util::exit() throws an exception object whose rc is
# ModPerl::EXIT
# (see modperl_perl_exit() and modperl_errsv() C functions)
-if ($@ && !(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
-$self->log_error($@);
-return Apache::SERVER_ERROR;
+if ($@) {
+if ($@ == APR::ECONNABORTED) {
+# silently ignore client connection abort
+}
+elsif (!(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
+$self->log_error($@);
+return Apache::SERVER_ERROR;
+}
}
return Apache::OK;
}
Not quite--now I get this:
[Mon Aug 02 13:59:29 2004] [error] [client [ip address]] Argument
"Software caused connection abort at [script path]" isn't numeric in
numeric eq (==) at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/ModPerl/RegistryCooker.pm
line 723, line 20.\n, referer: [referring page]
I guess the problem is that, unlike $!, $@ doesn't have a numeric
component. I tried changing this to:
+if ($@) {
+if ($@ eq APR::ECONNABORTED) {
+# silently ignore client connection abort
but that didn't help. Now it says, "APR::Error: Can't handle 'eq' at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/APR/Error.pm line 39,
line 20.\n".
Next idea? :-)
Ah, OK, APR::Error exception has got stringified already when it reached
that code. Well, really the fix shouldn't be there. This is going to hit
any modperl handlers, not only registry. So we should have a better
solution.
In mod_perl 1, many API calls were silently failing, so those broken
connection failures were silent. In mp2, it's the other way around - no
failure go unnoticed, unless you code it to be so.
Are you sure you want to ignore those things? I suppose that should be
the case.
To start with I want to have a short test case that I can reproduce the
problem with. Too bad you had it happening only over SSL. We need to
check the Apache source to see, who else sends APR__ECONNABORTED and
hopefully have a simpler test. do you know if you were hitting it on the
reading of the request or sending the response?
Add the following:
use APR::Error;
$SIG{__DIE__} = \&APR::Error::confess;
in your startup.pl, so now the trace will show you which line in the
code it has failed in.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
>> yes, clearly there is a bug in there, but not where you think - what is
>> important is that apache needs to do the same thing on GET as HEAD,
>> not that
>> there is no C-L generated for contentless HEAD requests. this patch more
>> accurately represents the real bug which, IIRC, httpd is already aware of
>> (at least I'm recalling discussion about a C-L of 0).
>
>
> Why do you say so? Your patch respresents a related, but a different
> issue. Boris has a problem with HEAD, and that's what the test was testing.
ok, maybe I was misunderstanding the discussion and subsequent test. my
points are these:
- apache has essentially full reign over the C-L header - it decides
whether it is required or not, regardless of whether or not you call
ap_set_content_length
- more important than whether the C-L header shows up or not for a given
HEAD or GET request is whether apache is consistent with itself. that is,
regardless of what _you_ think it should do, apache _knows_ what it should
do and should do it consistently between GET and HEAD.
- of course, printing a C-L header to stdout works around all of this -
apache can only manage things when you use the official API, since it checks
the headers_out table and not the actual content.
so, the test, as it existed before, made me think that the problem you saw
was in that final test, that adding content magically made the C-L header
appear. my point was that as long as apache does whatever it does
consistently between GET and HEAD it's not a bug. but maybe I'm just not
seeing it, so if you guys grok all of that and still see an issue, let's
flesh it out.
>
> But, certainly please commit it, rename the files to something different
> (content_length_header.t?) since it's not longer a HEAD request. And
> please add a comment explaining the bug, ideally with xref to a bugzilla
> for the bug you are talking about or discussion thread.
will do.
> also please move that no strict thing, inside the block, where it is
> needed. Thanks.
>
>> +no strict qw(refs);
>> +foreach my $method qw(GET HEAD) {
d'oh!
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: apache::session::mysql: layout
I could be wrong, but I think this is because the data stored in the a_session field, even though it is "TEXT" format, is actually stored as perl storage stuff that the command line can't display. All I know is it shows blank for me when I look at it from the mysql shell command line, but it works fine when I read it into my mod_perl scripts using DBI. If you try this command 'select * into outfile 'dump.txt' from sessions', you can see the actual stuff in the file you dump. Hope this helps. Casey Songer At 03:51 PM 8/1/04, Mark Copper wrote: I created a table "sessions" in my db with columns "id" and "a_session" per the Apache::Session::Store::MySQL pod, in particular, "a_session" is of type text. Everything worked fine but I have a (rather silly) question: Why can't I see the key/value pairs when I simply "select a_session from sessions" at the mysql shell prompt? Sheepishly, Mark -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::Registry: Software caused connection abort
At 11:35 AM -0700 8/2/04, Stas Bekman wrote: To start with I want to have a short test case that I can reproduce the problem with. Too bad you had it happening only over SSL. We need to check the Apache source to see, who else sends APR__ECONNABORTED and hopefully have a simpler test. I'm not sure I could come up with a test case, even if it wasn't an SSL-only thing. It also seems to depend on the browser being IE, so it's likely that LWP couldn't be used to reproduce the problem. Let me give it a try, though. If I come up with a test case, I'll send it along. do you know if you were hitting it on the reading of the request or sending the response? Upon sending the response. The original error message happens in my code when I try to "print" the HTTP header. This is somewhat unrelated: I was also playing around last week with some replacement "print" code to test $RequestRec->connection()->aborted() to see if the connection has been dropped before printing, but it doesn't seem to work. I always get a false return from that function in this case. I didn't look to see what method that function is using to detect the abort, but it doesn't work in this situation. -- Dan Wilga [EMAIL PROTECTED] Web Technology Specialist http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075"Who left the cake out in the rain?" -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
Geoffrey Young wrote:
yes, clearly there is a bug in there, but not where you think - what is
important is that apache needs to do the same thing on GET as HEAD,
not that
there is no C-L generated for contentless HEAD requests. this patch more
accurately represents the real bug which, IIRC, httpd is already aware of
(at least I'm recalling discussion about a C-L of 0).
Why do you say so? Your patch respresents a related, but a different
issue. Boris has a problem with HEAD, and that's what the test was testing.
ok, maybe I was misunderstanding the discussion and subsequent test. my
points are these:
- apache has essentially full reign over the C-L header - it decides
whether it is required or not, regardless of whether or not you call
ap_set_content_length
- more important than whether the C-L header shows up or not for a given
HEAD or GET request is whether apache is consistent with itself. that is,
regardless of what _you_ think it should do, apache _knows_ what it should
do and should do it consistently between GET and HEAD.
See my explanation of what I think is the problem at the end of this email.
- of course, printing a C-L header to stdout works around all of this -
apache can only manage things when you use the official API, since it checks
the headers_out table and not the actual content.
eh? how exactly do you do that? without assbackwards ofcourse.
so, the test, as it existed before, made me think that the problem you saw
was in that final test, that adding content magically made the C-L header
appear.
Actually I the problem I saw was exactly what Boris was talking about:
The C-L header wasn't there. The test simply exercises 4 different
combinations of sending and not sending C-L header and content.
my point was that as long as apache does whatever it does
consistently between GET and HEAD it's not a bug. but maybe I'm just not
seeing it, so if you guys grok all of that and still see an issue, let's
flesh it out.
I think it's there. The test that shows that is:
{
# if the response handler sends no data, and sets C-L header,
# the client doesn't get C-L header
my $uri = "$location?set_content_length";
my $res = $method->($uri);
ok t_cmp $res->code, 200, "$method $uri code";
ok t_cmp $res->header('Content-Length'), undef, "$method $uri
C-L header";
ok t_cmp $res->content, "", "$method $uri content";
}
As I didn't know what's the right thing that should happen, I didn't
make it a failure. But it probabaly shouldn't be undef in the C-L check.
But the fact that sending a bogus char and a different C-L header works
with HEAD (gets the C-L header through), whereas not sending any output
breaks, seems like a bug to me. As mentioned earlier I think the bug is
in the headers_out filter, which received EOS (since on HEAD apache
scratches the response body) and no body. So it takes the liberty to
nuke the C-L header, which I'm not sure is a good thing. When we send
some body, headers_out sends the headers before seeing EOS and therefore
it can't tell whether the body is coming or not, so it leaves the C-L
header alone. Which is at least inconsistent.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ERROR when compiled mod_perl with Apache assertion "rv == APR_SUC CESS" failed
Stas Bekman wrote:
SALOME Alexandre wrote:
Good Morning everybody, I need your help.
I have installed APACHE2.0.50 with PHP4. I would like to work with ssl. To
this, I am trying installed mod-perl1.99_14. When I compiled this, I have
this message:
[Mon Aug 02 09:02:02 2004] [crit] [Mon Aug 02 09:02:02 2004] file vhost.c,
line 189, assertion "rv == APR_SUCCESS" failed
. Please, what do Ido?
Looks like something is broken trying to resolve 255.255.255.255 on your platform
as seen by this snippet from vhost.c:
else if (strcasecmp(host, "_default_") == 0
|| strcmp(host, "255.255.255.255") == 0) {
rv = apr_sockaddr_info_get(&my_addr, "255.255.255.255", APR_INET, port, 0, p);
ap_assert(rv == APR_SUCCESS); /* must be bug or out of storage */
^
So, please submit a proper bug report and make sure you are giving out details of
the exact OS/Platform you are running on. All points to a problem in apr/httpd land,
not mod_perl though.
First you submit a proper problem report, as explained here:
http://perl.apache.org/bugs/
Make sure to mention when do you get this error. and show us a small
relevant config section which causes this error.
Thanks.
--
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature
Re: ModPerl::Registry: Software caused connection abort
Dan Wilga wrote: At 11:35 AM -0700 8/2/04, Stas Bekman wrote: To start with I want to have a short test case that I can reproduce the problem with. Too bad you had it happening only over SSL. We need to check the Apache source to see, who else sends APR__ECONNABORTED and hopefully have a simpler test. I'm not sure I could come up with a test case, even if it wasn't an SSL-only thing. It also seems to depend on the browser being IE, so it's likely that LWP couldn't be used to reproduce the problem. Let me give it a try, though. If I come up with a test case, I'll send it along. do you know if you were hitting it on the reading of the request or sending the response? Upon sending the response. The original error message happens in my code when I try to "print" the HTTP header. Yeah, that's what I thought. I suppose we could handle that internally then. But I want to have a failing test first. It should work with LWP, just as you see in LWP. Not sure how to arrange that with LWP. Ideas? We need to start the request and then kill it. I suppose we could do an alarm handler, but with 5.8.0 safe signals things, I'm not sure it will actually work. Can you give it a try? This is somewhat unrelated: I was also playing around last week with some replacement "print" code to test $RequestRec->connection()->aborted() to see if the connection has been dropped before printing, but it doesn't seem to work. I always get a false return from that function in this case. I didn't look to see what method that function is using to detect the abort, but it doesn't work in this situation. Are you by chance using a proxy server? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp1]: different output under perlrun and CGI
Gunnar Koppel wrote:
Terr!
I got some differencies between using script under CGI and
Apache::PerlRun what i don't understand is that mandatory.
I am not an expert, so i try just to describe my situation.
I have an CGI-script with following sub:
sub PHeader {
$_[0]
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
I call this sub mostly &PHeader and only if i need "Content-type:
text/plain" i add a argument &PHeader(1), for example.
Under CGI it works fine, but under Apache::PerlRun has @_ a value (for
example "Apache::PerlRun=HASH(0x81ea01c) SCALAR(0x821a2bc)", i don't
know where and why it comes) and my PHeader does not understand that i
need a HTML-header. When i call a sub like &PHeader() or PHeader, it
works fine, so main program does not deliver any arguments.
That's very simple ;-)
When running under Apache::PerlRun (or Apache:Registry), your script is
wrapped in a subroutine, that gets a few arguments passed in.
So, from the perlsub manpage:
To call subroutines:
NAME(LIST);# & is optional with parentheses.
NAME LIST; # Parentheses optional if predeclared/imported.
&NAME(LIST); # Circumvent prototypes.
&NAME; # Makes current @_ visible to called subroutine.
So, when you are calling ⊂ you are propagating the @_ of the current
scope down to that subroutine. As a rule of thumb, you should always calls
subs like sub() unless you _explicitely_ need to propagate @_ down to the
subroutine.
Maybe it is something trivial but i had really confused why i got wrong
headers. When i ran it from command line, i got right header (like under
CGI).
Maybe someone can explain, why under PerlRun i got value for @_?
My system is Debian GNU/Linux Stable, Apache is 1.3.29, mod_perl 1.29,
perl 5.8.3.
example script:
#!/usr/bin/perl -w
use strict;
use CGI qw(:all);
our ($q, $char);
$q = new CGI;
$char = "iso-8859-15";
&PHeader;
# &PHeader() or PHeader works fine;
&PContent;
sub PHeader {
@_
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
sub PContent {
@_
? print "some plain text -> @_"
: print "some HTML-content";
}
Output of `perl -V`
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.4.25-ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.25-ti1211 #1 thu feb 19 18:20:12 est 2004
i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dpriv
lib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr
-Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/per
l5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.3
-Dsitearch=/usr/local/lib/perl/5.8.3 -Dman1dir=/usr/share/man
/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=
3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.3 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LA
RGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.3 (Debian 20040314)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.3
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 27 2004 16:21:10
@INC:
/etc/perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
RE: [mp1]: different output under perlrun and CGI
> -Original Message-
> From: Gunnar Koppel [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 02, 2004 1:21 PM
> To: [EMAIL PROTECTED]
> Subject: [mp1]: different output under perlrun and CGI
>
>
> Terr!
>
> I got some differencies between using script under CGI and
> Apache::PerlRun what i don't understand is that mandatory.
>
> I am not an expert, so i try just to describe my situation.
>
> I have an CGI-script with following sub:
>
> sub PHeader {
> $_[0]
> ? print $q->header(-type=>"text/plain; $char",-cookie=>'')
> : print $q->header(-type=>"text/html; $char",-cookie=>'');
> }
>
> I call this sub mostly &PHeader and only if i need "Content-type:
> text/plain" i add a argument &PHeader(1), for example.
>
> Under CGI it works fine, but under Apache::PerlRun has @_ a value (for
> example "Apache::PerlRun=HASH(0x81ea01c) SCALAR(0x821a2bc)", i don't
> know where and why it comes) and my PHeader does not understand that i
> need a HTML-header. When i call a sub like &PHeader() or PHeader, it
> works fine, so main program does not deliver any arguments.
>
Gunnar:
I have to admit, I'm not familiar with the internals of PerlRun, but
my bet is your problem is related to the fact that calling a sub in the
format "&subname" (without a null param list), is treated like
calling it as "&subname(@_)".
from the perlsub perl docs:
(http://www.perldoc.com/perl5.8.4/pod/perlsub.html#DESCRIPTION)
If a subroutine is called using the & form, the argument list is optional,
and if omitted, no @_ array is set up for the subroutine: the @_ array at
the time of the call is visible to subroutine instead. This is an efficiency
mechanism that new users may wish to avoid.
&foo(1,2,3);# pass three arguments
foo(1,2,3); # the same
foo(); # pass a null list
&foo(); # the same
&foo; # foo() get current args, like foo(@_) !!
foo;# like foo() IFF sub foo predeclared, else "foo"
-
Looking briefly at Apache/PerlRun.pm (mod_perl 1),
I see sub_wrap is wrapping the script into a handler sub routine:
my $sub = join(
'',
'package ',
$package,
';use Apache qw(exit);',
'sub handler {',
$line,
$$code,
"\n}", # last line comment without newline?
);
And a handler gets passed $r (the apache request).
So, @_ is populated in your scripts "main" section, and is
being passed to your subroutine (because of the way you are
calling your subroutine).
In summary, if you want a null list passed to your sub, you probably
should explicidly send it a null list.
Hope this helps,
Mike
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2, HEAD request and Content-Length
> As mentioned earlier I think the bug is
> in the headers_out filter, which received EOS (since on HEAD apache
> scratches the response body) and no body. So it takes the liberty to
> nuke the C-L header, which I'm not sure is a good thing. When we send
> some body, headers_out sends the headers before seeing EOS and therefore
> it can't tell whether the body is coming or not, so it leaves the C-L
> header alone. Which is at least inconsistent.
ok, I think I see what is going on, but it's different than what you see :)
first, apache calls the C-L filter, which has no regard for any existing C-L
header and calculates its own if it can. so, in your test case the call to
$r->set_content_length(25) is overwritten by the real C-L of zero, as
calculated by the C-L filter.
next the header filter kicks in. inside the header filter is this bit of logic:
if (r->header_only
&& (clheader = apr_table_get(r->headers_out, "Content-Length"))
&& !strcmp(clheader, "0")) {
apr_table_unset(r->headers_out, "Content-Length");
}
which treats HEAD requests with a C-L of zero as a special case. and, in
fact, that is what you have sent it, at least in the test case. this is why
GET and HEAD differ in this instance, because you haven't sent any real
content and a C-L of 0 is special.
so, I don't see the bug. well, I do see it, except that it is intentionally
coded to be as such, which turns the bug into a feature.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::Registry: Software caused connection abort
At 12:02 PM -0700 8/2/04, Stas Bekman wrote: Upon sending the response. The original error message happens in my code when I try to "print" the HTTP header. Yeah, that's what I thought. I suppose we could handle that internally then. But I want to have a failing test first. It should work with LWP, just as you see in LWP. Not sure how to arrange that with LWP. Ideas? We need to start the request and then kill it. I suppose we could do an alarm handler, but with 5.8.0 safe signals things, I'm not sure it will actually work. Can you give it a try? I'm using LWP::UserAgent::timeout (which essentially uses alarm), and am not having any luck reproducing the problem yet. The timeout does happen, but apparently LWP drops the connection in a different way from IE, because the error doesn't occur. I'm even using SSL to test this. I also tried setting the user agent string of the request to match what IE sends, and this made no difference. I'm beginning to wonder if maybe I need to sniff the packets. Are you by chance using a proxy server? Nope. Good thought, though. -- Dan Wilga [EMAIL PROTECTED] Web Technology Specialist http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075"Who left the cake out in the rain?" -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
mp1: different output under perlrun and CGI
Terr!
I got some differencies between using script under CGI and
Apache::PerlRun what i don't understand is that mandatory.
I am not an expert, so i try just to describe my situation.
I have an CGI-script with following sub:
sub PHeader {
$_[0]
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
I call this sub mostly &PHeader and only if i need "Content-type:
text/plain" i add a argument &PHeader(1), for example.
Under CGI it works fine, but under Apache::PerlRun has @_ a value (for
example "Apache::PerlRun=HASH(0x81ea01c) SCALAR(0x821a2bc)", i don't
know where and why it comes) and my PHeader does not understand that i
need a HTML-header. When i call a sub like &PHeader() or PHeader, it
works fine, so main program does not deliver any arguments.
Maybe it is something trivial but i had really confused why i got wrong
headers. When i ran it from command line, i got right header (like under
CGI).
Maybe someone can explain, why under PerlRun i got value for @_?
My system is Debian GNU/Linux Stable, Apache is 1.3.29, mod_perl 1.29,
perl 5.8.3.
example script:
#!/usr/bin/perl -w
use strict;
use CGI qw(:all);
our ($q, $char);
$q = new CGI;
$char = "iso-8859-15";
&PHeader;
# &PHeader() or PHeader works fine;
&PContent;
sub PHeader {
@_
? print $q->header(-type=>"text/plain; $char",-cookie=>'')
: print $q->header(-type=>"text/html; $char",-cookie=>'');
}
sub PContent {
@_
? print "some plain text -> @_"
: print "some HTML-content";
}
Output of `perl -V`
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.4.25-ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.25-ti1211 #1 thu feb 19 18:20:12 est 2004
i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dpriv
lib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr
-Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/per
l5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.3
-Dsitearch=/usr/local/lib/perl/5.8.3 -Dman1dir=/usr/share/man
/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=
3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.3 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LA
RGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.3 (Debian 20040314)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.3
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 27 2004 16:21:10
@INC:
/etc/perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
--
TIA and with best regards
Kõike hääd,
Gunnar Koppel
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
