RE: Content-Type not working on MSIE
Greetings. [...] The issue: The simplest script I can't think of doesn't work. my $r = shift; $r-send_http_header(text/plain); $r-print(hello world); When I try to access the script, my MSIE 6.0 prompts for download when it should simple print the hello world string. Isn't it? [...] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /perl/test.pl HTTP/1.0 [...] What I'm doing wrong?? I do not think it is you. But, I have observed that IE sometimes tries to outfox Content-type when the extension of the url maps to one of the locally registered file types. Therefore, if perl (AS) is installed on the client machine, IE will disregard Content-type in favor of the local file association. If this is the case, then changing the extension from .pl to (nothing) should give you the expected result, as would requesting /perl/test.pl?foo=bar instead than /perl/test.pl. As an aside, if anyone on the list knows of ways to defang this really annoying IE behavior, I would be most interested in knowing about it Cheers, alf
[mp2] Post-request operations
Hi, In mod_perl 2 under MPM (win32), is there a way of returning the request to the client (browser) and having the script continue doing other (time consuming) operations (without the client having to wait). Under mp1/linux I guess I could fork but how can I do this on win32? A typical example could be to receive a file upload, return OK to the client, and then convert the file to some other format(s). thanks, -Kurt. __ kurt george gjerde [EMAIL PROTECTED] intermedia uib, university of bergen
Re: PerlSendHeader On
[ Please keep it on the list ... ] Bleicke Holm wrote: [Thu Mar 20 11:16:40 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26 mod_perl/1.26 configured -- resuming normal operations [Thu Mar 20 11:16:40 2003] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec) [Thu Mar 20 11:16:40 2003] [info] Server built: Nov 5 2002 06:43:12 [Thu Mar 20 11:16:40 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) Looks OK to me... It should not show mod_perl/1.26 twice in that line. What happens if you just take your working cgi-bin part and change the SetHandler and add PerlHandler so it runs through mod_perl? It doesn't work anymore... (I added PerlSendHeader On, too) Do you have any ScriptAlias statements in your conf file? Have you tried changing from Options ExecCGI to Options +ExecCGI? I think you should try to strip down the conf file as far as you possibly can and then post the whole thing here. There may be something else that you defined somewhere which is interfering with mod_perl. - Perrin
RE: notes() and mod_perl ErrorDocuments
Thanks, that worked. Now I can use the regular authentication stuff.
As I said in my last email, in the interest of preventing location
pollution, is there some way I could make those PerlSetVars available to
subsequent requests to a different location? I can't think of any way
to do it without copying them to a separate location for each one.
Perhaps with some kind of shared memory?
Brian
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2003 3:12 PM
To: Hann, Brian
Subject: Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote:
Well, here's my main problem. I will have many locations in many
vhosts that require authentication. Each of those locations defines
separate PerlSetVars that the authentication module picks up. I would
really, really like those vars to come across to whatever handles the
401 without having to declare a 401 location directive for every
authentication location directive, i.e. keep from having /auth_fail2,
auth_fail_bob, auth_fail_fred, etc. all over the vhosts:
well, you might be able to do something like
($r-prev || $r)-dir_config-get('system_id') to dig them out of the
main
request.
--Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote: Thanks, that worked. Now I can use the regular authentication stuff. As I said in my last email, in the interest of preventing location pollution, is there some way I could make those PerlSetVars available to subsequent requests to a different location? I can't think of any way to do it without copying them to a separate location for each one. Perhaps with some kind of shared memory? well, given your example setup Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user ErrorDocument 401 /auth_fail_bob /Location /Location /auth_fail_bob SetHandler perl-script PerlHandler AuthFailure PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 /Location I would think you could make that ErrorDocument 401 /auth_fail Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user /Location /Location /auth_fail SetHandler perl-script PerlHandler AuthFailure /Location the use the $r-prev() trick - requests to /bob that result in 401 errors handled by /auth_fail will have bob's PerlSetVar stuff in $r-prev-dir_config, same for /bill and /biff. is that not what you mean? --Geoff
RE: notes() and mod_perl ErrorDocuments
Partially, and yes that seems to work. But here's the thing: When a user fails to enter a good password they will be given a chance to enter questions like What is your mother's maiden name, etc. and get their account unlocked. Without passing the enc_key and system_id in form parameters, is there any way I could make them available to whichever handler that is for the full series of requests? The handler gets those values when the user first gets to auth_fail but after that there isn't really any way I can keep passing them on, is there? Thanks, Brian -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 1:45 PM To: Hann, Brian Cc: [EMAIL PROTECTED] Subject: Re: notes() and mod_perl ErrorDocuments Hann, Brian wrote: Thanks, that worked. Now I can use the regular authentication stuff. As I said in my last email, in the interest of preventing location pollution, is there some way I could make those PerlSetVars available to subsequent requests to a different location? I can't think of any way to do it without copying them to a separate location for each one. Perhaps with some kind of shared memory? well, given your example setup Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user ErrorDocument 401 /auth_fail_bob /Location /Location /auth_fail_bob SetHandler perl-script PerlHandler AuthFailure PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 /Location I would think you could make that ErrorDocument 401 /auth_fail Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user /Location /Location /auth_fail SetHandler perl-script PerlHandler AuthFailure /Location the use the $r-prev() trick - requests to /bob that result in 401 errors handled by /auth_fail will have bob's PerlSetVar stuff in $r-prev-dir_config, same for /bill and /biff. is that not what you mean? --Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote: Partially, and yes that seems to work. But here's the thing: When a user fails to enter a good password they will be given a chance to enter questions like What is your mother's maiden name, etc. and get their account unlocked. Without passing the enc_key and system_id in form parameters, is there any way I could make them available to whichever handler that is for the full series of requests? The handler gets those values when the user first gets to auth_fail but after that there isn't really any way I can keep passing them on, is there? nope, except by virtue of redirecting them back to /bob and starting the cycle over again. --Geoff
RE: Content-Type not working on MSIE
Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. (1) Fool IE by snarfing another extension in the URL. For example, instead of requesting http://www.example.com/foo.pl, tack on a dummy parameter and request http://www.example.com/foo.pl?filename=foo.txt. (2) Send a Content-Disposition header. This is a MIME header and not in the HTTP spec but IE respects it: Content-Disposition: inline; filename=foo.txt Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Content-Type not working on MSIE
On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. (1) Fool IE by snarfing another extension in the URL. For example, instead of requesting http://www.example.com/foo.pl, tack on a dummy parameter and request http://www.example.com/foo.pl?filename=foo.txt. I don't think this works with everything. (2) Send a Content-Disposition header. This is a MIME header and not in the HTTP spec but IE respects it: Content-Disposition: inline; filename=foo.txt I know that this doesn't work for all browsers. Our solution was to do a simple path info that was basically irrelevent. http://foo.bar.com/path/to/fetchfile.pl/foobar.pdf Every browser we tested it on tried to save the file as foobar.pdf. Rob
Re: Content-Type not working on MSIE
Robert Landrum wrote: On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. Can someone please summarize the problem and add possible solutions and post it here so we can add it to this document: http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html I think this doc should be renamed to ie_bugs.html ;) __ 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
Re: Content-Type not working on MSIE
Hello,
SBCan someone please summarize the problem and add possible solutions and
SBpost it here so we can add it to this document:
SBhttp://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html
Sometimes, MSIE will ignore the MIME type specified in a Content-Type
header, and instead guess the type of a file based on its extension. For
example, on most Windows systems files with a .reg extension are registry
files. So if you happen to have a Perl script on your mod_perl webserver
called foo.reg, even if it outputs a Content-Type: text/plain webserver,
MSIE may treat the output from the URL as a registry file (and pop up a
dialog box asking if you want to run the file, e.g., attempt to merge
its contents with the registry, in this example).
This is especially a problem if the computer running MSIE does something
special for .pl files (for example, feed the file to ActiveState Perl).
Here is how to reproduce the bug. Make a simple script like this:
#!/usr/local/bin/perl -w
use strict;
use Apache ();
my $r = Apache-request;
$r-content_type('text/plain');
$r-send_http_header;
$r-print('ok');
Call it plain.reg, and associate .reg files with Apache::Registry. An
.htaccess entry like this may do the trick:
FilesMatch \.reg$
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
/FilesMatch
Now if you access http://www.example.com/plain.reg with MSIE, you may
trigger this bug. (I'm not positive what causes MSIE to ignore
Content-Type on some extensions but not others. If plain.reg doesn't work
for you, try plain.exe, plain.bin, or some other file extensions.)
There are a variety of workarounds.
Easiest is to just fool IE, by making it think the script is named
something else. Most foolproof is to use extra path information:
http://www.example.com/plain.reg/plain.txt
You can also append a dummy parameter. Apparently, MSIE uses a simple
string match to find the extension.
http://www.example.com/plain.reg?bogus=plain.txt
Finally, MSIE respects the Content-Disposition MIME header. This isn't
officially part of the HTTP spec, but is especially useful because you can
suggest a filename. This is nice so that if the user does Save As... or
if your script produces a CSV file or some other application specific
output, a pretty filename will be suggested. Just include a line like this
in the Apache::Registry script before calling send_http_header():
$r-header_out('Content-Disposition' = 'inline; filename=plain.txt');
I just verified all of this on freshly patched IE 6.
Humbly,
Andrew
--
Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED]
Engineer1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
--
Re: Content-Type not working on MSIE
Hello, AGcalled foo.reg, even if it outputs a Content-Type: text/plain webserver, s/webserver,/header,/ Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Content-Type not working on MSIE
Heyas, AHFinally, MSIE respects the Content-Disposition MIME header. This isn't AHofficially part of the HTTP spec, but is especially useful because you AHcan suggest a filename. One more addition. While poking around RFC 2616 for some other stuff I found that Content-Disposition is in fact mentioned in it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1 Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
cvs version make test errors
Hi All, I got a version from cvs today and make test fails with: protocol/echo_filter...ok protocol/eliza.skipped all skipped: cannot find module 'Chatbot::Eliza' All tests successful, 3 tests skipped. Files=115, Tests=610, 230 wallclock secs (115.33 cusr + 30.32 csys = 145.65 CPU) *** server localhost:8529 shutdown *** port 8529 still in use... done cd ModPerl-Registry gmake test gmake[1]: Entering directory `/de1/src/lima/modperl-2.0/ModPerl-Registry' /usr/local/perl-5.8.0_threaded/bin/perl -I../blib/arch/Apache2 -I../blib/lib/Apache2 \ t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/local/perl-5.8.0_threaded/bin/perl -I../blib/arch/Apache2 -I../blib/lib/Apache2 \ t/TEST *** root mode: changing the fs ownership to 'nobody' (60001:60001) /usr/local/WASM_Sessions_Checker_apache_2.0.44/bin/httpd -d /de1/src/lima/modperl-2.0/ModPerl-Registry/t -f /de1/src/lima/modperl-2.0/ModPerl-Registry/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS using Apache/2.0.44 (worker MPM) waiting for server to start: ... waiting for server to start: ok (waited 14 secs) server localhost:8529 started 206ok 404ok 500ok bad_scriptsok basic..ok closureok perlrun_requireok redirect...ok special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e special_blocks.dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 6-12 Failed 7/12 tests, 41.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- special_blocks.t 29 7424127 58.33% 6-12 *** server localhost:8529 shutdown !!! error running tests (please examine t/logs/error_log) gmake[1]: *** [run_tests] Error 1 gmake[1]: Leaving directory `/de1/src/lima/modperl-2.0/ModPerl-Registry' gmake: *** [run_tests] Error 2 Sincerely, Jie perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=solaris, osvers=2.7, archname=sun4-solaris-thread-multi uname='sunos lima 5.7 generic_106541-23 sun4u sparc sunw,ultra-80 ' config_args='-Dcc=gcc -B/usr/ccs/bin/ -Doptimize=-O2 -Dprefix=/usr/local/perl-5.8.0_threaded -Dusethreads -Ui_db -Uuselargefiles -Uusemymalloc -Dlocincpth=/usr/local/include /opt/local/include /include /usr/include -Dloclibpth=/usr/local/lib /opt/local/lib /usr/lib /usr/ccs/lib' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc -B/usr/ccs/bin/', ccflags ='-D_REENTRANT -fno-strict-aliasing -I/opt/local/include', optimize='-O2', cppflags='-D_REENTRANT -fno-strict-aliasing -I/opt/local/include' ccversion='', gccversion='3.2.2', gccosandvers='solaris2.7' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, prototype=define Linker and Libraries: ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib -L/opt/local/lib -L/usr/lib -L/usr/ccs/lib' libpth=/usr/local/lib /opt/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldl -lm -lrt -lpthread -lc perllibs=-lsocket -lnsl -ldl -lm -lrt -lpthread -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -L/opt/local/lib -L/usr/lib -L/usr/ccs/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT Built under solaris Compiled at Mar 21 2003 11:50:43 @INC: /usr/local/perl-5.8.0_threaded/lib/5.8.0/sun4-solaris-thread-multi /usr/local/perl-5.8.0_threaded/lib/5.8.0 /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/sun4-solaris-thread-multi /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0 /usr/local/perl-5.8.0_threaded/lib/site_perl .
Re: cvs version make test errors
Jie Gao wrote: Hi All, I got a version from cvs today and make test fails with: special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e Thanks Jie. Your bug report missing the mod_perl and apache information. You should have run t/REPORT to get this as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I can't tell whether you are running a threaded-mpm or a prefork. However, this is not a bug in mod_perl, but a current limitation in one of the testing framework functionalities. Certain tests need to make sure that they hit the same interpreter twice in a row (e.g. to test the closure effect), apparently the current implementation doesn't work well on several platforms, win32 included. If somebody (preferrably on a platform that has this problem) can look at this issue and resolve it, that would be a great help. You can find the code in Apache-Test/lib/Apache/TestRequest.pm and you have several tests that use it (grep for 'same_interp_tie'). The currently used algorithm is very simple: the first request stores the unique id of the perl interpreter in the response headers and on the following requests the client supplies this header. Apache::TestRequest resubmits the request again and again till it hits the same interpreter and only then returns the response to the client. After TRY_TIMES (50) it'll give up and return an error. I'm not sure whether raising of this number to let's say 500 will help to solve the problem. Your help is appreciated. __ 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
Re: cvs version make test errors
On Fri, 21 Mar 2003, Stas Bekman wrote: Date: Fri, 21 Mar 2003 14:09:11 +1100 From: Stas Bekman [EMAIL PROTECTED] To: Jie Gao [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: cvs version make test errors Jie Gao wrote: Hi All, I got a version from cvs today and make test fails with: special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e Thanks Jie. Your bug report missing the mod_perl and apache information. You should have run t/REPORT to get this as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I can't tell whether you are running a threaded-mpm or a prefork. However, this is not a bug in mod_perl, but a current limitation in one of the testing framework functionalities. Certain tests need to make sure that they hit the same interpreter twice in a row (e.g. to test the closure effect), apparently the current implementation doesn't work well on several platforms, win32 included. If somebody (preferrably on a platform that has this problem) can look at this issue and resolve it, that would be a great help. You can find the code in Apache-Test/lib/Apache/TestRequest.pm and you have several tests that use it (grep for 'same_interp_tie'). The currently used algorithm is very simple: the first request stores the unique id of the perl interpreter in the response headers and on the following requests the client supplies this header. Apache::TestRequest resubmits the request again and again till it hits the same interpreter and only then returns the response to the client. After TRY_TIMES (50) it'll give up and return an error. I'm not sure whether raising of this number to let's say 500 will help to solve the problem. Your help is appreciated. Guess what, I ran the test again, it passed. :-) I figure this had to do with the load of the machine. Anyway, I was using threaded-mpm with apache 2.0.44. Many thanks, Jie
Re: cvs version make test errors
Jie Gao wrote: I got a version from cvs today and make test fails with: special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e Thanks Jie. Your bug report missing the mod_perl and apache information. You should have run t/REPORT to get this as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I can't tell whether you are running a threaded-mpm or a prefork. However, this is not a bug in mod_perl, but a current limitation in one of the testing framework functionalities. Certain tests need to make sure that they hit the same interpreter twice in a row (e.g. to test the closure effect), apparently the current implementation doesn't work well on several platforms, win32 included. If somebody (preferrably on a platform that has this problem) can look at this issue and resolve it, that would be a great help. You can find the code in Apache-Test/lib/Apache/TestRequest.pm and you have several tests that use it (grep for 'same_interp_tie'). The currently used algorithm is very simple: the first request stores the unique id of the perl interpreter in the response headers and on the following requests the client supplies this header. Apache::TestRequest resubmits the request again and again till it hits the same interpreter and only then returns the response to the client. After TRY_TIMES (50) it'll give up and return an error. I'm not sure whether raising of this number to let's say 500 will help to solve the problem. Your help is appreciated. Guess what, I ran the test again, it passed. :-) I figure this had to do with the load of the machine. Anyway, I was using threaded-mpm with apache 2.0.44. Thanks. However this still needs to be fixed, as random failures aren't good enough. __ 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
