Re: Double erroneous requests in POST with multipart/form-data
What are you using to parse the request? CGI.pm? Mark Maunder wrote: This has got me stumped, any help is much appreciated: I'm using IE6 and mod_perl 1.27 with apache 1.3.27. I have mod_rewrite and mod_proxy and mod_gzip compiled into the server, but have now disabled all of them until I sort this problem out. IE generates a request who's headers look like this from a sniffer's point of view: POST /e/myg HTTP/1.1 Accept: */* Referer: http://ziptree.com/e/myg Accept-Language: en-us Content-Type: multipart/form-data; boundary=---7d31a435d08 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Host: ziptree.com Content-Length: 797 Connection: Keep-Alive Cache-Control: no-cache Cookie: ztid=52616e646f6d4956aca247f49143acab646412868d6eda23; ztid=52616e646f6d495616e14f825d3799273ac52995e708d08b It's only generating on request - I've double checked that. But in my access log I see this: 68.5.106.9 - - [16/Jul/2003:14:37:51 -0500] POST /e/myg HTTP/1.1 200 16 68.5.106.9 - - [16/Jul/2003:14:37:51 -0500] -7d31a435d08 501 - (The two lines above have probably been split by your mail reader, but they both start with the ip 68.5...) Also, intermittently I get Invalid method in request reported in the error_log like this: [Wed Jul 16 14:37:51 2003] [error] [client 68.5.106.9] Invalid method in request -7d31a435d08 It looks like Apache is getting confused by the boundary data and thinks it's another request. It's occured to me that this could be a bug in IE incorrectly specifying the boundry? One of the unpleasant side effects of this is that my user loses their session because what Apache considers the first 'request' does not contain a cookie, so we just issue a fresh session ID which overwrites the previous one. I found these in the list archives, but no replies to either. http://groups.yahoo.com/group/modperl/message/34118 http://groups.yahoo.com/group/modperl/message/52778
Re: Content compression FAQ
Slava Bizyayev wrote: It should not be considered a bugfix anymore. It is NOT required to do, because that particular story with M$IE is over. Sounds like we agree to disagree on this one. My opinion would be, if there is a known problem with a browser version that can be solved with a minimum amount of disruption to other users, then it's worth doing. For me, the prospect of adding at most 46 bytes to a compressed response is worth it. For people who need every last bit of bandwidth performance, it may not be. Hence, the bugfix should be optional. I understand that microsoft have a patch for the problem, the issue is how many people actually are using the patch? Probably the vast majority to be sure, but there ain't no way of telling. or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore.
Re: How practical is that Practical mod_perl?
or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore. Personally, I would recommend not to deal with deflate when possible. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: how to secure perl modules?
you seem to be talking about two different things here. firstly, do you want to protect your source code being viewed by other people? secondly, do you want to ensure that your code is only being run on computers that you have authorised? these are related problems, but each requires a different method of solving it. the other question that is useful to ask is how many days of effort will be required to secure your program and compare that with how much your clients would value that amount of time being used in development of new features instead? uru -Dave Kirk Rogers wrote: i have a collection of perl modules (running under the mod_perl umbrella) and would like to distribute the application to several different sources (clients with open internet web servers). but i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. what options do i have (if any) to secure the code so that it can't be 'easily' stolen? 'easily' being the operative word here, as i realize it wont be 100% safe no matter what i do. the ideal would be to perhaps encrypt some of the code, maybe a few of the base configuration modules, maybe even the startup.pl file, others? any suggestions would be appreciated, thanks
Re: Please wait Handler
Last time I experimented with Server-Push, the only browser that implemented it was Netscape 4.*. Mozilla didn't and IE didn't. Which is a pity cos it's a really useful technique. Perrin Harkins wrote: Martin Moss wrote: I was wondering if it is possible to Create a Handler that points a user at a page with an animated gif saying something like Please wait, and then when my other handlers have finished display the page results I want from my mod perl handlers. The classic answer to this problem is described by Randal in one of his Web Techniques columns: http://www.stonehenge.com/merlyn/WebTechniques/col20.html You can also try server push (with the Content-type: multipart/x-mixed-replace header), but I'm not sure how consistently today's browsers implement that. - Perrin
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Stas Bekman wrote: Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me?
Re: test failed; ... t/httpd.conf
Hmmm. Are you by any chance female? :) Please don't mess about with file ownerships, groups, permissions and things if you aren't sure of what you're doing. That's dangerous in a Webserver and besides you can get in a real mess with the installation. I'm probably just over-sensitive, but if i was getting frustrated with one of my servers and copped a call like that, i'd be booking a ticket to jubileegroup.co.uk armed with a cricket bat... :) I wouldn't have a clue what is going vickie, but i ran the same set of commands on my linux box and it executed no worries. If ya want, I can send the gzipped output (about 2k) off-list to give you something to compare against?
Re: Environment variable in Apache/mod_perl/IO::Socket
G'day Dean,
I just tried it and it seemed to work fine. (i just tried connecting to
my db instead and printed the value of $socket to STDERR). The only
question I have is where are $socket, $host and $port defined? They do
not seem to be local to the routine, so is it possible that is where the
confusion is happening?
Uru
-Dave
dhfg wrote:
Hi,
In my web application, I am using Apache server with mod_perl. In one of my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
Re: Environment variable in Apache/mod_perl/IO::Socket
I'm on Linux 2.4.20, with Apache 1.3.27, mod_perl 1.27, perl 5.6.1,
connecting locally to a postgres db. My previous guess had to be wrong
because you said the code
worked if you replaced
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
with
$socket = new IO::Socket::INET(
PeerAddr = 'gaia',
PeerPort = ,
Proto= 'tcp')
or die Cannot connect to $port at $host;
Have you tried just extracting the code to a small test program,
defining the environment variables on the command line and running it
through the perl debugger?
dhfg wrote:
Hi David,
The $socket, $host, and $port are all defined locally, ie. my $host, $port,
$socket (I missed them out while writing the email). What platform are you
trying it out. I have the socket client running within the Apache server on
the Solaris and making the connection to the Socket server running on a
Window XP PC. Wonder if this may cause the problem.
Cheers,
Dean
-Original Message-
From: David Dick [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 6 February 2003 7:17 PM
To: dhfg
Cc: [EMAIL PROTECTED]
Subject: Re: Environment variable in Apache/mod_perl/IO::Socket
G'day Dean,
I just tried it and it seemed to work fine. (i just tried connecting to
my db instead and printed the value of $socket to STDERR). The only
question I have is where are $socket, $host and $port defined? They do
not seem to be local to the routine, so is it possible that is where the
confusion is happening?
Uru
-Dave
dhfg wrote:
Hi,
In my web application, I am using Apache server with mod_perl. In one of
my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set
in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved
correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
Re: Possible bug with a 206 Partial Response
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT = 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
Uru
-Dave
Ged Haywood wrote:
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than one in the past...
73,
Ged.
Re: Different modules, same names, random results
this is probably evil, and apologies to those who have seen suspiciously
familiar code before, but is this possible?
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
}
sub handler {
delete $INC{'Site.pm'};
# mess with @INC
require Site;
return (Apache::Registry::handler(@_));
}
END { }
1;
that would allow you to keep perl resident, keep the cgi-scrip resident
and simply reload a small? configuation perl module each time.
(i think?) :)
Uru
-Dave
Pinunki wrote:
Hello everyone,
I am currently running a web server using Perl CGI for
all my web sites and have been attracted to mod_perl
for the performance advantages - particularly not
having to start a new perl interpreter for each
request. I have tried using Apache::Register and
Apache::PerlRun but am having problems due to the fact
that each web site refers to their own copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
The following example is using Apache::PerlRun (as
it's supposed to be more forgiving that
Apache::Register). I am using Apache 1.3.26 and
mod_perl 1.26 on Debian Woody.
.htaccess
-
PerlModule Apache::PerlRun
files *.pl
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
/files
site1.pl
#!/usr/bin/perl
use strict;
use CGI;
use lib lib1;
use Site;
my $q = new CGI;
print $q-header();
print EOF;
Site 1br
VAR: $VARbr
EOF
lib1/Site.pm
#!/usr/bin/perl -w
package Site;
require Exporter;
use strict;
our $VAR = Site one;
our @ISA = qw(Exporter);
our @EXPORT = qw($VAR);
1;
site2.pl
#!/usr/bin/perl
use strict;
use CGI;
use lib lib2;
use Site;
my $q = new CGI;
print $q-header();
print EOF;
Site 2br
VAR: $VARbr
EOF
lib2/Site.pm
#!/usr/bin/perl -w
package Site;
require Exporter;
use strict;
our $VAR = Site two;
our @ISA = qw(Exporter);
our @EXPORT = qw($VAR);
1;
I then call site1.pl and site2.pl multiple times and
get output like this:
Site 1
VAR: Site two
Site 1
VAR: Site one
Site 1
VAR: Site two
Site 2
VAR: Site two
Site 2
VAR: Site two
Site 2
VAR: Site one
I can fix this problem by adding the line PerlSetVar
PerlRunOnce On to my .htaccess file, but my
performance tests show that this is actually slower
than regular CGI!!
Is there anything I can do to make this work properly
without renaming all my Site.pm modules (and all
scripts that call them) to have unique names?
Thanks,
Pinunki
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Possible bug with a 206 Partial Response
If I'm correct both Apache::PerlRun and Apache::Registry will have problems in certain situations if we agree that ModPerl::Registry has the correct logic for handling the execution status. If you can tell otherwise please give me a test script that doesn't work under ModPerl::Registry. But in your particular example, Dick, if you configure the I'm presuming that you simply mixed up which is my first name and surname? :) Usually dave is fine. :) script to run under Apache::RegistryNG, does it work? No. If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script. well the ModPerl::Registry behaviour certainly suits my program. :) Uru -dave
Re: Possible bug with a 206 Partial Response
Good Point. Forgot to mention that the error log is completely empty. :) Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Got a bit of a weird set of behaviour with a mod_perl Apache::Registry type script. [snip] More information about this error may be available in the server error log.P [snip] Anyone got any ideas? What does it say in the error_log? 73, Ged.
Re: Possible bug with a 206 Partial Response
not even getting a broken connection. So somehow mod_perl doesn't _really_ think it's an error. Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
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 '?xml versi';
}
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
?xml versi!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE206 Partial Content/TITLE
/HEADBODY
H1Partial Content/H1
The server encountered an internal error or
misconfiguration and was unable to complete
your request.P
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.P
More information about this error may be available
in the server error log.P
/BODY/HTML
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
VirtualHost *
ErrorLog /var/log/httpd/error_log
Directory /
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
/Directory
/VirtualHost
