Possible bug with a 206 Partial Response
G'day all,
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
HISTORY:
I've been using MD5 digests of the html sent from my scripts as ETags,
hence saving an important bit of bandwidth. Got a little bit carried
away with the success of this project and attempted to handle range
requests as well. Worked fine when running as a CGI script, but blew a
fuse when running as an Apache::Registry script. Stripped the script
down to the basics and the error continued.
I have a script called test.pl which has the following content.
#! /usr/bin/perl -wT
MAIN: {
print <<_OUT_;
Status: 206 Partial Content
Content-Type: text/html; charset=UTF-8
Content-Length: 11
Content-Range: bytes 0-10/1336
Date: Fri, 31 Jan 2003 09:39:01 GMT
ETag: ""
_OUT_
print '
}
When the script is run, the following output appears.
[dave@localhost]$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.pl HTTP/1.1
Host: localhost
HTTP/1.1 206 Partial Content
Date: Sat, 01 Feb 2003 22:12:47 GMT
Server: Apache
Content-Range: bytes 0-10/1336
ETag: ""
Content-Length: 11
Content-Type: text/html; charset=UTF-8
206 Partial Content
Partial Content
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.
More information about this error may be available
in the server error log.
Fairly obviously, not what is desired. However, if you change the '206'
in the script to a '200', the script works fine. I've searched through
the mod_perl code in a brief fashion for a condition that would cause
this, but couldn't find anything. Anyone got any ideas?
CONFIGURATION
apache 1.3.27
mod_perl 1.27
mod_ssl 2.8.11-1.3.27
httpd.conf
ServerType standalone
ServerTokens ProductOnly
Timeout 300
KeepAlive On
KeepAliveTimeout 100
MaxKeepAliveRequests 10
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 20
MaxRequestsPerChild 10
BindAddress 127.0.0.1
Port 80
User nobody
Group nobody
UseCanonicalName On
DefaultType text/plain
HostnameLookups Off
ServerSignature Off
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /path/to/script/parent
ErrorLog /var/log/httpd/error_log
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Re: mod_perl and mod_cgi problems
Thanks! I've actually made some kind of progress on this case... I've found a workaround... I don't fully like it, so if anyone got a sugestion for aprovement, please tell me! This was the "problem area" in my old httpd.conf: (...) AddHandler cgi-script .cgi AddHandler perl-script .mpl PerlHandler Apache::Registry I've converted it into this: AddHandler perl-script .cgi PerlHandler Apache::PerlRun PerlSetVar PerlRunOnce On AddHandler perl-script .mpl PerlHandler Apache::Registry This works fine, but it will only work for perl-scripts and not for shell-scripts. Well, to bad! For the perl-script part it actually runs faster! Apache don't need to fork any new processes to compile the cgi... If I add the following line to my httpd.conf: AddHandler cgi-script .sh This will most likely (not tested) fail like .cgi did when I used cgi-script-handler in apache... So the problem aren't solved yet! Stas Bekman wrote: The latest "Linker patch" are installed on the server... In that case I hope that somebody else who's on Solaris could step in and help. I do hope that someone can explain to me why mod_cgi and mod_perl don't work well together. It worked just fine using apache 1.3.14 and mod_perl 1.X (another version I can't remember). But with apache 1.3.27 and mod_perl 1.27, it didn't.
about @INC and handlers directory
Hi!!! Well this is my firts post in this list... I have a server with several domains which each of them has its own handlers, subroutines and there are several common subrutines. What i want to do it is organize the directory structure, so: /modperl/domain_1/ /modperl/domain_2/ /modperl/domain_3/ /modperl/domain_n/ /modperl/common/ Inside of each one, the handler and subroutines of each domain. The the handlers are: PerlHandler domain_1 ... PerlHandler domain_n to use the common subroutines: common::subroutine_n Now my questions: 1) is this directory structure correct??? 2) can it be improve??? 3) security matters? 4) IMPORTANT: how to set the @INC and where any help, tips, URL are welcome Thanks in advance
Re: Stacked Handlers Execution Chain
Yes, with the newest cvs, it works like expected! Thank you all for your help! Helmut --On Mittwoch, 29. Januar 2003 12:05 +1100 Stas Bekman <[EMAIL PROTECTED]> wrote: Try again with the current cvs. You can look at the test t/hooks/TestHooks/stacked_handlers.pm which aborts the execution chain when Apache::DONE is returned. __ 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: mod_perl and current directory (was Re: Newbie Q on Apache::Include)
At 06:22 PM 1/28/2003, Stas Bekman wrote: [...] > Is it true what was said in one of the other threads -with mod_perl (Apache 1.3.27) the current working directory is different from the dir where the script lies? [...] As I've followed up (because I knew that that particular post will create confusion), it *is* the script's dir for mod_perl 1.x. (Apache::Registry and friends) Ok Tks I guess I should have read the thread carefully. It's *currently* not the case with mod_perl 2.0 (ModPerl::Registry and friends), but this should change to be the same as 1.x by the time 2.0 is released. __ 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
Is Sys::Signal still needed?
Searching the archives I don't see much discusson of Sys::Signal. Is it still needed to restore sig handlers? Thanks, -- Bill Moseley [EMAIL PROTECTED]
