Multiple Cookie Header Bug with Apache::ProxyRewrite
hello, Christian
I found a bug with how Apache::ProxyRewite handles cookies.
Our proxy server was trying to display a remote application that heavily uses cookies
butthe application was failing miserably.
I compared the headers of what the proxy server was sending to the client vs. what the
remote server was displaying. the proxy server was only sending one (the last one) of
4 Set-Cookie headers.
The problems lies in the way that all headers are set:
$r-headers_out-{$header} = $value;
I patched the server by changing sum code in: sub respond { }
to allow for multiple cookie headers.
Here is what I did:
# feed reponse back into our request_record
$response-scan(sub {
my ($header, $value) = _;
$r-log-debug(respond: OUT $header: $value);
if ($header =~ /^Set-Cookie/i) {
$value =~ /path=([^;]+)/i;
my $cookie_path = $1;
rewrite_url($r, $remote_site, \$cookie_path, $mapref);
$value =~ s/(path=)([^;]+)/$1$cookie_path/i;
# Multiple Cookie Patch added by amen
# 04/03/2002
$r-headers_out-add( 'Set-Cookie' = $value );
$r-log-debug(respond: OUT-MOD $header: $value);
} else {
$r-headers_out-{$header} = $value;
}
});
Makes sense :)
thanx for writing this,
-amen
BTW we are using version 0.15
Re: WebDAV support in mod_perl
I am very interested in any developments in this area. I currently am doing dav stuff in Java for macromedia.com and would be interested in porting it to my first love: Perl! please let me know of any developments. I am willing to help, if you need it. cheers, -amen On Wed, 29 Nov 2000, Ian Kallen wrote: Yes, I've contemplated either: 1) implementing the DAV protocols entirely in Perl for mod_perl 2) gluing in XS into mod_dav -- IIRC mod_dav has hooks for non-filesystem respositories; it'd be great just to expose that API to mod_perl (haven't cracked open that code yet though) Issues: what will be required to implement DeltaV (I need concurrent checkouts and versioning) as well? What's up with the expat-lite in Apache conflicting with XML::Parser's expat? Given a clear picture of these options and issues, I'd be more than pleased to bang out a good Apache::WebDAV code base implementation. -Ian Today, Joao Pedro Goncalves [EMAIL PROTECTED] frothed and gesticulated about...: Hi, is there any current project going on for using the WebDAV protocol in mod_perl, something like Apache::WebDAV? I am familiar with the mod_dav efforts however they seem to be oriented to filesystem repositories and i would like to use WebDAV in a more dynamic environment such as repositories being in a database, or for supporting new stuff like Outlook HTTPmail, that uses WebDAV to connect to Hotmail. If not, is there any people out there interested in starting one? Core features of the WebDAV protocol already have several CPAN modules that would help its development, such as locking and XML processing. Thanks in advance, Joao Pedro -- João Pedro Gonçalves www.sapo.pt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Salon Internethttp://www.salon.com/ Manager, Software and Systems "Livin' La Vida Unix!" Ian Kallen [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: STDIN and subrequests
thanx, Andrei That could work. However, am I not limited to a certain size GET string? Or are GET strings of unlimited size when issued internally by a SubRequest and not an actual client? One definite problem is that that cgi in question would need to know how to handle both GET and POST requests. Some legacy cgi on our servers may only know how to do one or the other. any other ideas? -amen "Andrei A. Voropaev" wrote: I feel like it would be simpler to append content of STDIN to the URL. In other words convert POST request to GET. Andrei On Wed, Aug 23, 2000 at 10:03:59PM -0700, Alex Menendez wrote: hello, all I am currently trying to have a cgi execute in a mod_perl module by generating a subrequest to the executable via lookup_uri. It is working great for GET requests. However, POST requests are obviously failing because only the uri is being passed to the subrequest and not the main request's STDIN. I assume the answer is to tie the main request's STDIN to the subrequest's STDIN. I have tried to to this with tie but I get an error because the subclass Apache::SubRequest cannot execute a tie. Any ideas? -amen --
Re: executing a cgi from within a handler (templating redux)
H, the do does seem a little inefficient. I solved this problem in the
past by intiating a subrequest and changing the stack handler to
cgi-script right before running the cgi. something like this:
$subr = $r-lookup_uri($uri);
if($r-filename =~ /\.(cgi|pl)$)/o) {
$subr-handler('cgi-script');
}
$subr-run();
you might get into some trouble with headers if your cgi's return
http headers other than just Content-type like Location. If they don't go
ahead and add $r-send_http_header right before the run command. If they
do send other headers, you will need a patch for Apache.xs in the mod_perl
src. I have it and can give it to you if you are interested.
-amen
On Wed, 23 Aug 2000, Todd Finney wrote:
Hi,
I'm building a simple templating system. The major
requirement of the system is that allow custom dynamic
headers, footers, and toolbars based upon the identity of
the user.
The system so far works like this:
- a user enters the site and logs in. The names
of the user's default
template, header, footer, and toolbar are placed
into a cookie
(via Apache::Session).
- when the user requests a page, my handler
intercepts that request, and
looks at the user's cookie. Based upon the
information in it, it grabs the
appropriate template and components from the
filesystem along with the
requested page, rolls them together, and serves
the result.
A sample template file looks like this:
html
headtitleStandard Template/title/head
body bgcolor="#ff"
table width="650" cellspacing="0" cellpadding="0"
border="0"
trtd colspan="2" width="650" align="left"!--
Wrapper:header --br/td/tr
tr
td width="150" align="left" valign="top"!--
Wrapper:toolbar --br/td
td width="500" align="left" valign="top"!-- Content
--br/td/tr
trtd colspan="2" width="650" align="left"!--
Wrapper:footer --br/td/tr
/table
/body/html
Component files, such as the header, footer and toolbar,
are by convention self-contained html tables, ala
# file components/tool/standard
table width="100%"
trtd align="center"a href="/wrapped/one.html"Link
One/abr/td/tr
trtd align="center"a href="/wrapped/two.html"Link
Two/abr/td/tr
trtd align="center"a href="/wrapped/three.html"Link
Three/abr/td/tr
trtd align="center"a href="/wrapped/four.html"Link
Four/abr/td/tr
trtd align="center"a href="/wrapped/five.html"Link
Five/abr/td/tr
trtd align="center"a
href="/wrapped/cgi-bin/test.pl"CGI/abr/td/tr/table
I have a working version of this handler, but I think that
there's a better way to do it, specifically the part that
manages the content return part of the request. Static
files are simple enough; I open the file and print it to
STDOUT. Scripts, however, need to be handled
differently. The way I'm doing it now works, but it
strikes me as inefficient.
package My::Wrapper;
use strict;
use Apache::Constants qw(:common DONE);
use Apache::Log ();
sub handler {
my ( $r ) = shift;
my ( $log ) = $r-log;
$log-info("Wrapper: Inside Wrapper.");
my ( $template_directory ) = "/www/html/templates/";
my ( $components_directory ) =
'/www/html/components/';
#
# these next four variables will come from the cookie,
they are
# set manually for now.
#
my ( $template ) = $template_directory.'standard';
my ( $header ) =
$components_directory.'head/'.'standard';
my ( $toolbar ) =
$components_directory.'tool/'.'standard';
my ( $footer ) =
$components_directory.'feet/'.'standard';
$r-send_http_header;
if ( -e $template ) {
open( TEMPLATE, "$template" ) or die "Failed to
open template $template: $!";
while (TEMPLATE) {
if ( $_ =~
/(.*)\!--\sWrapper:(\w+)\s--(.*)/o ) {
my ( $before ) = $1;
my ( $component ) = $2;
my ( $after ) = $3;
my ( $name );
$name = $header if $component eq 'header';
$name = $toolbar if $component eq
'toolbar';
$name = $footer if $component eq 'footer';
print $before; print_component($name);
print $after;
} elsif ( $_ =~ /(.*)\!--\sContent\s--(.*)/o
) {
my ( $before ) = $1;
my ( $after ) = $2;
my ( $file ) = $r-filename;
print $before;
if ( -e $file ) {
if ( $file =~ /(?:cgi|pl)$/ ) {
$log-info("Wrapper: cgi script
requested.");
do $file;
} else {
$log-info("Wrapper: static file
requested.");
open(CONTENT, "$file" ) or die
"Failed to open content file $file: $!";
while (CONTENT) {
print $_;
STDIN and subrequests
hello, all I am currently trying to have a cgi execute in a mod_perl module by generating a subrequest to the executable via lookup_uri. It is working great for GET requests. However, POST requests are obviously failing because only the uri is being passed to the subrequest and not the main request's STDIN. I assume the answer is to tie the main request's STDIN to the subrequest's STDIN. I have tried to to this with tie but I get an error because the subclass Apache::SubRequest cannot execute a tie. Any ideas? -amen
Re: cgis and subrequests
h,
I have tried what you suggested and it is still not generating the
headers. I have tried calling the send_http_header function both before
and after the handler switch and it still is not working. I think it is
bug but I am not sure. At any rate, here is some of the module code and
the http.conf directives:
my $uri = $r-uri;
unless(!$r-args) {
$uri = $uri .'?'.$r-args;
}
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-send_http_header;
$subr-run();
my $status = $subr-status;
$subr-print(create_img_tag($file,$SCRIPT_ON,$status));
return $status;
Files ~ "\.(html|htm|shtml|fhtml)$"
SetHandler perl-script
PerlHandler Macromedia::AddStatImage
/Files
Files ~ "\.(cgi|pl|sh)$"
SetHandler perl-script
PerlHandler Macromedia::AddStatImage
PerlSetVar is_cgi 1
/Files
any ideas?
-amen
On Mon, 21 Aug 2000, Doug MacEachern wrote:
On Sun, 20 Aug 2000, Alex Menendez wrote:
unfortunately, I am not entirely sure what a cgi is going to output all the
time. The cgi might try to do a redirect using the Location field. Therefore,
I don't think I can simply send_http_headers as type text/html...
right,
my $lookup = $r-lookup_uri( $uri );
$r-send_http_header( 'text/html' );
so just change that line to:
$lookup-send_http_header;
and you'll get the content-type and headers generated by the subrequest.
if there's a bug, it's in the book, subrequest-run() is not supposed to
include headers in the output.
Re: cgis and subrequests
ok, what about cgi's that generate Location: headers. Am I out of luck here? should I contemplate changing src for ap_run_sub_req thanx, -amen On Mon, 21 Aug 2000, Doug MacEachern wrote: whoops. yeah, $subr-send_http_header won't work for the same reason send_http_header() calls within run() do not. you'll just need to propagate subrequest info like so: my $subr = $r-lookup_uri($uri); $r-send_http_header($subr-content_type); $subr-run;
Re: Passing a hash to a cgi outside a form?
you can't do this, dude. test.cgi dies and so do all it's pointers to
structures in memory.
try looking at Apache::Registry or mod_perl with the Apache::Filter
mod.
Or if you want to keep these things as cgi's look at LWP which lets you
make http requests from within perl programs.
However, I would probably just make some subroutines that both cgis could
use via require or use. the memory structures still are destroyed when the
cgi dies.
It really depends if your intent is to reuse code or pass a
structure that is already in memory. if it is the former, look at LWP or
the subroutine example. if it is the former, checkout the mod_perl and
Filter stuff.
hope this helps,
-amen
On Mon, 21 Aug 2000, perl wrote:
Hi there!
Sorry for this question which might sound easy to you, but, does anyone know :
How can a CGI pass and receive a hash without a form?
Please have a look at the following simple scripts :
This is test.cgi
---
#!/usr/bin/perl
use CGI;
$list-{'value1'} = 'apple';
$list-{'value2'} = 'fruit';
print "Location: test2.cgi?list=$list \n\n";
--
This is test2.cgi
--
#!/usr/bin/perl
use CGI qw (:standard);
print header;
$list = param('list');
foreach (keys %{$list})
{
print "KEY IN LIST = ",$_,br;
}
--
Thank you for your help !
Re: cgis and subrequests
hey, guys
just for the recordI finally got this thing to work. However, it does
have some bizarre behavior. After compiling the patch,
$subr-run(1) returns headers without calling the send_http_header method.
This holds true for static files and for cgis that only set the content type
header. For cgis that add any additional header like Location, the headers
are not returned unless you explicitly call send_http_header. I know that
our cgi's at most only alter the Location header in addition to content
type...so...I coded around this with the following:
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-run(1);
if($subr-header_out('Location')) {
$subr-send_http_header;
} else {
$r-print(create_img_tag($file,$SCRIPT_ON,$status));
}
my $status = $subr-status;
return $status;
if I always called send_http_header, a second set of HTTP headers would be
appended to static documents and to cgis that only change the content type
header.
Just an FYI...
-amen
Doug MacEachern wrote:
On Mon, 21 Aug 2000, Alex Menendez wrote:
ok, what about cgi's that generate Location: headers. Am I out of luck
here? should I contemplate changing src for ap_run_sub_req
doh, right, headers are not added until run(). no need to change
ap_run_sub_req, we can support this. with the patch below you can say
$subr-run(1), where 1 enables send_http_header() within subrequests.
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 19:38:32
@@ -1996,10 +2003,15 @@
"Apache::SubRequest::DESTROY(0x%lx)\n", (unsigned long)r));
int
-run(r)
+run(r, allow_send_header=0)
Apache::SubRequest r
+int allow_send_header
CODE:
+if (allow_send_header) {
+r-assbackwards = 0;
+}
+
RETVAL = run_sub_req(r);
OUTPUT:
cgis and subrequests
Hello, all
I have a module that appends a line of stats sensitive information to
the bottom of html pages or
cgi scripts. the module uses lookup_uri() to generate a subrequest then
calls run() to output the actual contents of the file. the eagle book
says that calling run() on a subrequest should automatically send the
client the appropriate http headers and the document's body. However, I
have found that this is not the case. The following code does not send
http headers for both cgis and html docs. The body stuff is working fine
but the headers are not being sent:
my $uri = $r-uri;
unless(!$r-args) {
$uri = $uri .'?'.$r-args;
}
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-run();
my $status = $subr-status;
$r-print(create_img_tag($file,$SCRIPT_ON,$status));
return $status;
any ideas?
BTW create_img_tag just returns a string.
-amen
Re: cgis and subrequests
unfortunately, I am not entirely sure what a cgi is going to output all the
time. The cgi might try to do a redirect using the Location field. Therefore,
I don't think I can simply send_http_headers as type text/html...
thanx, though
-amen
Rick Myers wrote:
On Aug 20, 2000 at 19:38:53 -0700, Alex Menendez twiddled the keys to say:
cgi scripts. the module uses lookup_uri() to generate a subrequest then
calls run() to output the actual contents of the file. the eagle book
says that calling run() on a subrequest should automatically send the
client the appropriate http headers and the document's body. However, I
have found that this is not the case. The following code does not send
http headers for both cgis and html docs. The body stuff is working fine
but the headers are not being sent:
my $uri = $r-uri;
unless(!$r-args) {
$uri = $uri .'?'.$r-args;
}
my $subr = $r-lookup_uri($uri);
if($r-dir_config('is_cgi')) {
$subr-handler('cgi-script');
} else {
$subr-handler('server-parsed');
}
$subr-run();
my $status = $subr-status;
$r-print(create_img_tag($file,$SCRIPT_ON,$status));
return $status;
any ideas?
Yes. run() no longer sends headers (as far as I know). I don't know when
it was changed, but it pre-dates my experience. I've had the following
working just fine for close to a year now (or maybe my sense of time is
warped :).
my $lookup = $r-lookup_uri( $uri );
$r-send_http_header( 'text/html' );
my $status = $lookup-run;
$r-status( $status );
Rick Myers[EMAIL PROTECTED]
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
canned footers
hello, all I am trying to write a module that generates a canned footer for all html and cgi pages on my site. the html part is pretty easy and I have already implemented it. However, I am currently having trouble adding it to standalone cgi scripts that are not parsed by the server. I have tried a number of variations with mod_perl subrequests but none of them seem to work right. I also thought about reading the scripts contents in the module and using eval. However, that seems a little cumbersome. Have any of you implemented such thing before? Any ideas? -amen
Re: canned footers
Your right. this works great for html! Unfortunately, however, Apache sandwich really does not work for me because it only deals with GET requests and it can not deal with cgi requests directly. I would need to alter my cgi's in order to use sandwich. I am looking for a mod_perl solution that will add footers to unaltered stand alone cgis. any other ideas out there? thanx, -amen "Bruce W. Hoylman" wrote: Have you looked at Apache::Sandwich from CPAN? It is easy to implement and I have used it for awhile now to add confidentiality headers and footers to pages in a small to medium site. cpan m /Apache::Sandwich/ Module id = Apache::Sandwich CPAN_USERID VKHERA (Vivek Khera [EMAIL PROTECTED]) CPAN_VERSION 2.04 CPAN_FILEV/VK/VKHERA/Apache-Sandwich-2.04.tar.gz MANPAGE Apache::Sandwich - Layered document (sandwich) maker INST_FILE/opt/gnu/lib/perl5/site_perl/5.005/Apache/Sandwich.pm INST_VERSION 2.04 It could most certainly be use as a basis for your needs and requirements. Peace.
new cgi mod_perl question
does anyone know how to get the output of a standalone cgi script from a
mod_perl module
I have tried all the subrequest stuff but I can't get it to work.
Apache seems to parse the cgi file once a handler has been called. simply
writing a handler that returns DECLINED every time it is called like so:
package LameModule;
use Apache::Constants qw(:common);
sub handler {
my $r= shift;
return DECLINED;
}
with a config entry like so:
Files ~ "\.cgi$"
SetHandler perl-script
PerlHandler LameModule
/Files
will always parse the cgi file as text instead of just declining to handle
it and letting the cgi do its thing. Any ideas on how to get this cgi to
write some output to STDOUT even when a Handler has been called for its
file extension?
thanx,
-amen
regular cgis and mod_include and/or Apache::SSI
Hello, all I have a very simple problem for which I am sure (hope) there is a very simple solution. I basically want to pipe cgi output to mod_include or rather the equivalent mod_perl module, Apache::SSI. I do not want to make the cgis mod_perl modules nor Apache::Registery scripts. Just want to take their output and run it through an include type module that will parse server side includes if they exist. I looked into chaining modules (tying file handles) where one module is a fake module that just executes the cgi and the second would be the virtual include mod that takes the first ones output as input and does the actual work. However, this seems rather cumbersome to get such a simple thing done. Any ideas? thanx in advance, -amen
Re: Cookies and redirection
not completely sure about real mod_perl. However, the following works
great using Apache::Registry and CGI:
print $query-header(-cookie=[$id_cookie,$crypt_cookie],
-Location=$query-param("redirect").'?name='.@$ref[1].'last_login='.@$ref[3].'site_id='.$query-
param('site_id'));
I think Apache::Request will work just in same manner.
-amen
On Tue, 9 May 2000, Robin Berjon wrote:
At 00:13 09/05/2000 -0700, Perrin Harkins wrote:
Bill Desjardins wrote:
I checked the archives and the guide to no avail, so here goes. I am
having trouble setting a cookie in the header and then doing a
redirect. The cookies are working fine every where, but if I add a cookie
to $r-headers_out-add(), set a location via $r-headers_out(Location =
'newrui') and return REDIRECT, I get no cookies being set. is this a bug,
feature, or a feature of the wonderful world of incompatible browsers?
This is a known problem with certain browsers. The cookie will get set,
but will not get returned on this first redirect. You could try putting
the cookie data in a query string and looking for it there when it isn't
in the cookie.
Isn't there a work-around consisting of making 100% sure the cookie is sent
before the Location header ?
.Robin
All paid jobs absorb and degrade the mind. -- Aristotle
Parent Process Memory Space
Hello, All I currently have a caching module for dynamic pages that is loaded up upon server startup. However, when each child process uses this module they each create a copy of the modules caching hash. I would like to have 1 copy of the caching hash in the parent process that each child can read and/or write to. I have never used it before, however, the storable module seems to be the way to go. Is this correct? -amen
Re: simple xml parsing within html
yes, bill I am actually doing the same thing! however, I still would like a pre-cached transaction to run faster for those pages that are truly dynamic and can never really be cached effectively. -amen Bill Moseley wrote: At 08:47 PM 12/8/99 -0800, Alex Menendez wrote: I initially tried to do this by subclassing HTML::Parser and over-riding the usual methods. However, this was painfully slow.even after chunking the files line by line. You didn't mention how many different HTML files you need to parse, or their size, so this may or may not work for you. But on template files I use I only read and parse them once per child, and use a cache to store the most commonly used templates in the server process. This works well if just a few templates are used a vast majority of the time, and you have a little extra memory available. Bill Moseley mailto:[EMAIL PROTECTED]
DBI Performance with Multiple IDs
hello, all
Given the following situation what is more efficient:
-I have 10 id numbers I want to query on numbers 1,2,3,4,5,6,7,8,9,10
respectively. However, this list is not fixed and could be any number of
ids up to 20.
-Is it faster to create a global variable with a prepared sql statement
at the begining of the mod_perl script as follows:
$sth = $dbh-prepare('SELECT name FROM table_name WHERE id = ?');
then iterate through n number of ids later in the script for the
$sth-execute(1);
-Or is it faster to prepare the statement each time the script is
called with the following sql statement and execute once:
$sth = $dbh-prepare('SELECT name FROM table_name WHERE id IN
(1,2,3,4,5,6)';
$sth-execute;
Basically, A persistent sql handle with many executes VS a
non-persistent sql handle with one execute.
The dbh is cached and global for both...
thanx,
-amen
