Yes, it's ensembl :) Here is the output from envview ;)
SCRIPT_NAME => /perl/Gallus_gallus/envview SERVER_NAME => www.mydomain.org ENSEMBL_FIRSTSESSION_ID => 2 ENSEMBL_SPECIES => Gallus_gallus SERVER_ADMIN => webmaster@mydomain.org HTTP_ACCEPT_ENCODING => gzip, deflate HTTP_CONNECTION => Keep-Alive REQUEST_METHOD => GET HTTP_ACCEPT => image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* SCRIPT_FILENAME => /usr/local/ensembl/perl/default/envview HTTP_UA_CPU => x86 SERVER_SOFTWARE => Apache QUERY_STRING => REMOTE_PORT => 1248 HTTP_USER_AGENT => Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1) SERVER_PORT => 80 SERVER_SIGNATURE => HTTP_ACCEPT_LANGUAGE => en-gb HTTP_COOKIE => __utma=178564727.1690238308.1174479254.1175092438.1175502956.4; __utmz=178564727.1175502956.4.3.utmccn=(referral)|utmcsr=cl.iah.bbsrc.ac .uk|utmcct=/|utmcmd=referral; ENSEMBL_AJAX=activex; ENSEMBL_WWW_FIRSTSESSION=b6405de3f30eecfa0b122fed466e83c30b048c587adb301 71b780652 REMOTE_ADDR => 149.155.42.148 SERVER_PROTOCOL => HTTP/1.1 MOD_PERL_API_VERSION => 2 PATH => # long path so removed REQUEST_URI => /Gallus_gallus/envview GATEWAY_INTERFACE => CGI/1.1 ENSEMBL_SCRIPT => envview SERVER_ADDR => 149.155.40.20 DOCUMENT_ROOT => /usr/local/ensembl/htdocs HTTP_HOST => iahc-linux13.iah.bbsrc.ac.uk MOD_PERL => mod_perl/2.0.3 So it was a nice idea, but it would seem the scripts are running under mod_perl. You said that "It should be examining the output of contigview and mapview to determine if there's a content type header, and if not, it will send text/html.". As I cannot find the code in mapview or contigview, or in fact any of the other *views to print out the header, is it possible to assume that ensembl relies on apache/mod_perl's ability to do this, and for some reason, my version/installation of apache/mod_perl just isn't doing it? Are there any known bugs that could possibly be causing this behaviour? Many thanks Mick -----Original Message----- From: Robert Landrum [mailto:[EMAIL PROTECTED] Sent: 18 April 2007 17:11 To: michael watson (IAH-C) Cc: modperl@perl.apache.org Subject: Re: Malformed header from script michael watson (IAH-C) wrote: > > [Wed Apr 18 09:56:55 2007] [notice] Apache/2.2.4 (Unix) mod_perl/2.0.3 > Perl/v5.8.0 configured -- resuming normal operations > [Wed Apr 18 09:56:57 2007] [error] [client 149.155.40.20] malformed > header from script. Bad header=<head>: mapview > [Wed Apr 18 09:56:57 2007] [warn] /perl/Gallus_gallus/mapview did not > send an HTTP header > [Wed Apr 18 09:57:45 2007] [error] [client 149.155.42.148] malformed > header from script. Bad header=<head>: mapview > [Wed Apr 18 09:57:45 2007] [warn] /perl/Gallus_gallus/mapview did not > send an HTTP header So this is Ensembl were dealing with, correct? > > I must confess, I don't really know what the Apache::Registry and > ModPerl::Registry modules actually do, but the code in question is > handled by ModPerl::Registry. From httpd.conf (mostly a perl script!): > That's okay. I've never actually used either of them. In the CGI world, when a perl script is called it's read, parsed, compiled, and executed for each request. Then the script terminates. ModPerl::Registry reads, parses, and compiles the perl script once, and just keeps it in memory for any subsequent requests. The caveat is that sometimes global variables don't get reset to their original states because, well, the script doesn't ever exit. > $Location{"/perl"}={ > SetHandler => 'perl-script', > PerlHandler => 'ModPerl::Registry', > # Options => '+ExecCGI', > allow => 'from all', > # PerlSendHeader => 'On', > PerlOptions => '+ParseHeaders', > }; This all seems right. It should be examining the output of contigview and mapview to determine if there's a content type header, and if not, it will send text/html. I suspect that /perl may not actually be running in mod_perl. I would add a file to /perl called env. #!/usr/bin/perl print "Content-type: text/plain\n\n"; for (keys %ENV) { print "$_ => $ENV{$_}\n"; } That should print out a line like MOD_PERL => 'mod_perl/2.0.3' if it's working correctly. If not, it's a configuration problem. Maybe the /perl location config isn't in the virtual host you're using? Rob
