Apache::URI::hostname is blank
For some odd reason, Apache::URI::hostname is showing up as blank. I've tried reading the various man pages and the Oriley book, but I can't find any explanation for why hostname would be blank.. Am I overlooking something? Thanks in advance. -- Write the bad things that are done to you in sand, but write the good things that happen to you on a piece of marble.--Arabic proverb Adam Ness AIM: GreyLurk| YIM: greylurk1 LiveJournal: incarnate | Journalscape: incarnate _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Apache::URI::hostname is blank
Adam Ness wrote: For some odd reason, Apache::URI::hostname is showing up as blank. I've tried reading the various man pages and the Oriley book, but I can't find any explanation for why hostname would be blank.. Am I overlooking something? yes :) see Recipe 5.3 in the cookbook for the complete lowdown, but I'm pretty sure it's there in the eagle as well... for the moment, though, know that there are two ways of getting an Apache::URI object: my $uri = $r-parsed_uri; my $uri = Apache::URI-parse($r); parsed_uri() will only return the scheme, port, and hostname if the incoming URI is an absolute URI (which is typically the case with proxies but atypical for most of your programing). Apache::URI-parse($r) tries to find what it can from the request, then it makes decisions based on what else Apache knows about the server. typically this will involve populating $uri-hostname but, as someone brought up just recently, if you use a _default_ vhost config you'll get '_default_' for the hostname. there are other differences between the two methods, but this is what you're interested in now... --Geoff
Apache::URI - URI::URL?
Hey all. I seem to be coming onto the modperl scene a little late, and it seems one of the classes mentioned in the Eagle book no longer exists. I am trying to get the full URI (http(s)://servername/uri) from the Apache::URI class. Of course the Eagle mentions that URI::URL is schedulted to be replaced by URI.pm, but I'm not sure what the deal is there. Anyone wanna toss me a clue? I'm running FreeBSD and I see no ports to that effect, so I just want to know if a port should be written. TIA Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Vulcans never bluff. -- Spock, The Doomsday Machine, stardate 4202.1 msg22330/pgp0.pgp Description: PGP signature
Re: bugfix in Apache::URI
On Tue, 14 Aug 2001, Vyacheslav Zamyatin wrote: Hello all, Here is a small patch that prevents crash in the following example. $referer = 'http://some.host.com'; $uri = Apache;:URI-parse($req,$referer); $page = $uri-rpath; If parsed uri don't have path at all, it'll dump core in the last line. thanks, applied to cvs.
bugfix in Apache::URI
Hello all, Here is a small patch that prevents crash in the following example. $referer = 'http://some.host.com'; $uri = Apache;:URI-parse($req,$referer); $page = $uri-rpath; If parsed uri don't have path at all, it'll dump core in the last line. --- URI.xs Mon Apr 10 18:07:07 2000 +++ /root/src/mod_perl-1.24/src/modules/perl/URI.xs Tue Aug 14 11:17:57 2001 @@ -92,7 +92,8 @@ RETVAL = newSVpv(uri-uri.path, set); } else -RETVAL = newSVpv(uri-uri.path, 0); +if ( uri-uri.path ) +RETVAL = newSVpv(uri-uri.path, 0); OUTPUT: RETVAL -- See you in the Net, Slawa
RE: bugfix in Apache::URI
-Original Message- From: Vyacheslav Zamyatin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 14, 2001 4:15 AM To: [EMAIL PROTECTED] Subject: bugfix in Apache::URI Hello all, Here is a small patch that prevents crash in the following example. $referer = 'http://some.host.com'; $uri = Apache;:URI-parse($req,$referer); $page = $uri-rpath; If parsed uri don't have path at all, it'll dump core in the last line. hmmm... well, mod_perl shouldn't have to dump core over this, but a path component to the URI is required. but, it's a problem that has bitten me once or twice as well, so perhaps we ought to be helping the users somewhat in this case? what about defaulting the path to / if no path is present instead? I've actually thought about this in the past and wondered about the best solution. Ideas? --Geoff --- URI.xs Mon Apr 10 18:07:07 2000 +++ /root/src/mod_perl-1.24/src/modules/perl/URI.xs Tue Aug 14 11:17:57 2001 @@ -92,7 +92,8 @@ RETVAL = newSVpv(uri-uri.path, set); } else -RETVAL = newSVpv(uri-uri.path, 0); +if ( uri-uri.path ) +RETVAL = newSVpv(uri-uri.path, 0); OUTPUT: RETVAL -- See you in the Net, Slawa
Apache::URI problems
I'm seeing this problem both under mod_perl 1.25 and 1.26. I've installed mod_perl as a DSO outside of the Apache source tree using APXS. It seems to work fine, except for Apache::URI. Here's my test script: #!/usr/bin/perl use strict; use Apache::FakeRequest; use Apache::URI; my $req = Apache::FakeRequest-new( 'get_server_name' = 'dev1.aus1.datafoundry.net' ); my $uri = Apache::URI-parse( $req, 'main/test.html' ); print 'URI: ', $uri-unparse(), \n; print 'SCHM: ', $uri-scheme(), \n; print 'PATH: ', $uri-path(), \n; print 'RPTH: ', $uri-rpath(), \n; All I'm doing is some simple testing. The problem is, I'm getting this error: Can't locate object method parse via package Apache::URI (perhaps you forgot to load Apache::URI?) at t1 line 10. Looking at an old install of both perl and mod_perl (which are both not being used or considered), I see that there are actually three related URI files: /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/Apache/URI.pm /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.bs /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.so Under the version of perl I'm actually working with, though, only the first exists /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris/Apache/URI.pm How come the rest of the code for URI isn't being installed? Did something change at 1.25 to make it unnecessary? Am I doing something wrong? Does parse() not exist as a class method anymore (if so, the docs are out of date)? The perl being used has this configured for @INC: Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at May 14 2001 09:09:43 @INC: /usr/local/lib/perl5/5.6.1/i86pc-solaris /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl . Thanks in advance for any assistance, Philip * Philip Molter * Texas.net Internet * http://www.texas.net/ * [EMAIL PROTECTED]
cvs commit: modperl-2.0/xs/Apache/URI - New directory
dougm 01/04/28 15:28:12 modperl-2.0/xs/Apache/URI - New directory
RE: [RESEND] seg fault with Apache::URI ... weird
-Original Message-
From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 4:47 PM
To: Nick Tonkin
Cc: [EMAIL PROTECTED]
Subject: Re: [RESEND] seg fault with Apache::URI ... weird
[snip]
just to put everyone on the same page, looks like this is now fixed in
1.3.19-dev?
--Geoff
I've debugged the problem, but have no solution:
my $uri = Apache::URI-parse($r, $r-uri);
This calls ap_parse_uri_components(), which is responsible for setting
the scheme, hostname, user, password, port, path, etc. But,
the scheme is
not getting set, because the request line only contains
"/path" or such.
$uri-hostname($r-get_server_name);
$uri-port($r-get_server_port);
These work fine.
print $uri-unparse;
This calls ap_unparse_uri_components(). If there is a hostname but no
scheme, ap_unparse_uri_components() will pass a null argument to
strcasecmp, which will cause an invalid memory access and
SIGSEGV. You
can work around the problem by including
$uri-scheme('http'); with the
other accessor methods. In the long run this is probably a
bug in Apache.
If you read src/main/util_uri.c in Apache, you can see why
commenting out
one accessor avoids the crash.
Regards,
Jeffrey Baker
Re: [RESEND] seg fault with Apache::URI ... weird
On Fri, 9 Feb 2001, Jeffrey W. Baker wrote: [...] Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't segfault when given NULL pointers? Or does this mean that the version of Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code in Apache hasn't changed since then, so I assume a difference between BSD and Linux libc. Seems like it. We still use your code[1] on 4.2-STABLE with recent Apache+mod_perl and haven't had any problems while upgrading. so the conclusion: LINUX SUCKS![2] ;-) - ask [1] except $uri-port($r-get_server_port) is now $uri-port(80). [2] I do use Linux here and there, even RedHat (6.x though), so let's not start a long thread about which OS sucks less. -- ask bjoern hansen - http://ask.netcetera.dk/
Re: [RESEND] seg fault with Apache::URI ... weird
Hi Jeff,
Thanks for your feedback.
On Thu, 8 Feb 2001, Jeffrey W. Baker wrote:
On Thu, 8 Feb 2001, Nick Tonkin wrote:
Hi all,
No response on this so here it is again, any clues appreciated:
I am encountering a weird problem with Apache::URI ... consider, please,
this test handler:
[ ... ]
This code has worked fine for two years or more on my FreeBSD boxes; this
is on Linux RedHat 7 ... dunno if that makes a difference.
It doesn't make a difference. Segfaults for me on Slackware-current, too.
However, I would suggest avoinding RH 7.0 and its buggy compiler!
Jeez, I have had nothin but headaches with RedHat. I have always used
FreeBSD but it didn't know about the SCSI disks on the customer's HP
NetServer ... maybe I'll try again with Suse or Slackware before I get too
far along.
I've debugged the problem, but have no solution:
Thanks for getting in where my hands fear to get dirty ... :)
my $uri = Apache::URI-parse($r, $r-uri);
This calls ap_parse_uri_components(), which is responsible for setting
the scheme, hostname, user, password, port, path, etc. But, the scheme is
not getting set, because the request line only contains "/path" or such.
$uri-hostname($r-get_server_name);
$uri-port($r-get_server_port);
These work fine.
print $uri-unparse;
This calls ap_unparse_uri_components(). If there is a hostname but no
scheme, ap_unparse_uri_components() will pass a null argument to
strcasecmp, which will cause an invalid memory access and SIGSEGV. You
can work around the problem by including $uri-scheme('http'); with the
other accessor methods. In the long run this is probably a bug in Apache.
If you read src/main/util_uri.c in Apache, you can see why commenting out
one accessor avoids the crash.
Regards,
Jeffrey Baker
I wonder if you noticed that this code was from the Auth/Access stuff
you did for me a while back ... so I'll patch mine but you might want to
take a look at the places you are using it ...
Thanks again,
Nick
Re: [RESEND] seg fault with Apache::URI ... weird
On Fri, 9 Feb 2001, Nick Tonkin wrote: Hi Jeff, Thanks for your feedback. I wonder if you noticed that this code was from the Auth/Access stuff you did for me a while back ... so I'll patch mine but you might want to take a look at the places you are using it ... Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't segfault when given NULL pointers? Or does this mean that the version of Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code in Apache hasn't changed since then, so I assume a difference between BSD and Linux libc. Cheers, Jeffrey
Re: [RESEND] seg fault with Apache::URI ... weird
On Fri, 9 Feb 2001, Jeffrey W. Baker wrote: On Fri, 9 Feb 2001, Nick Tonkin wrote: Hi Jeff, Thanks for your feedback. I wonder if you noticed that this code was from the Auth/Access stuff you did for me a while back ... so I'll patch mine but you might want to take a look at the places you are using it ... Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't segfault when given NULL pointers? Or does this mean that the version of Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code in Apache hasn't changed since then, so I assume a difference between BSD and Linux libc. Yikes. I'm JAPH -- this (behavior of OS functions on different Unices) is out of my purview, I'm afraid. However, it is true that the identical code has worked on FreeBSD with Apache 1.3.[9-current or so] for at least a year without problems. HTH, Nick
[RESEND] seg fault with Apache::URI ... weird
Hi all,
No response on this so here it is again, any clues appreciated:
I am encountering a weird problem with Apache::URI ... consider, please,
this test handler:
package WM::Test;
use strict;
sub handler {
my $r = shift;
my $uri = Apache::URI-parse($r, $r-uri);
$uri-hostname($r-get_server_name);
$uri-port($r-get_server_port);
print $uri-unparse;
}
1;
__END__
As written, this causes a seg fault every time. Commenting out _either_
the $uri-hostname assignment _or_ the $uri-port assignment solves the
problem, or even changing the call to one or other of the methods from an
assignment to a read. But when both methods are assigned new values, seg
fault.
This code has worked fine for two years or more on my FreeBSD boxes; this
is on Linux RedHat 7 ... dunno if that makes a difference.
apache etc.:
[Sun Feb 4 10:53:11 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25
mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations
perl:
wm@wm ~/wm/perl/WMperl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i686-linux
uname='linux wm 2.2.16-22 #1 tue aug 22 16:49:06 edt 2000 i686 unknown
'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=2.96 2731 (Red Hat Linux 7.0)
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 30 2001 10:41:19
@INC:
/usr/local/lib/perl5/5.6.0/i686-linux
/usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i686-linux
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl
.
Thanks,
Nick
~~~
Nick Tonkin
Re: [RESEND] seg fault with Apache::URI ... weird
Hi there, On Thu, 8 Feb 2001, Nick Tonkin wrote: No response on this so here it is again, any clues appreciated: This code has worked fine for two years or more on my FreeBSD boxes; this is on Linux RedHat 7 ... dunno if that makes a difference. [snip] config_args='' This seems strange. cc='gcc', optimize='-O2', gccversion=2.96 2731 (Red Hat Linux 7.0) And wasn't there a problem with the compiler on RH7? I think there's something in the List archies. 73, Ged.
seg fault with Apache::URI ... weird
Hi all,
I am encountering a weird problem with Apache::URI ... consider, please,
this test handler:
package WM::Test;
use strict;
sub handler {
my $r = shift;
my $uri = Apache::URI-parse($r, $r-uri);
$uri-hostname($r-get_server_name);
$uri-port($r-get_server_port);
print $uri-unparse;
}
1;
__END__
As written, this causes a seg fault every time. Commenting out _either_
the $uri-hostname assignment _or_ the $uri-port assignment solves the
problem, or even changing the call to one or other of the methods from an
assignment to a read. But when both methods are assigned new values, seg
fault.
This code has worked fine for two years or more on my FreeBSD boxes; this
is on Linux RedHat 7 ... dunno if that makes a difference.
apache etc.:
[Sun Feb 4 10:53:11 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.25
mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations
perl:
wm@wm ~/wm/perl/WMperl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i686-linux
uname='linux wm 2.2.16-22 #1 tue aug 22 16:49:06 edt 2000 i686 unknown
'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=2.96 2731 (Red Hat Linux 7.0)
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 30 2001 10:41:19
@INC:
/usr/local/lib/perl5/5.6.0/i686-linux
/usr/local/lib/perl5/5.6.0
/usr/local/lib/perl5/site_perl/5.6.0/i686-linux
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl
.
Thanks,
Nick
~~~
Nick Tonkin
Re: seg fault with Apache::URI ... weird
Hi there, On Sun, 4 Feb 2001, Nick Tonkin wrote: I am encountering a weird problem with Apache::URI ... consider, please, this test handler: package WM::Test; [snip] As written, this causes a seg fault every time. I know this will sound strange, but would you, just for me, try calling the package something else other than "Test"? That cured a segfaulting mod_perl on Solaris for me last year. I never had the time to investigate why that fixed it. You probably won't want it to be called "Test" eventually anyway... 73, Ged.
Re: seg fault with Apache::URI ... weird
er, Test.pm is a ... test script. The seg fault presented itself in real code :) ~~~ Nick Tonkin On Sun, 4 Feb 2001, G.W. Haywood wrote: Hi there, On Sun, 4 Feb 2001, Nick Tonkin wrote: I am encountering a weird problem with Apache::URI ... consider, please, this test handler: package WM::Test; [snip] As written, this causes a seg fault every time. I know this will sound strange, but would you, just for me, try calling the package something else other than "Test"? That cured a segfaulting mod_perl on Solaris for me last year. I never had the time to investigate why that fixed it. You probably won't want it to be called "Test" eventually anyway... 73, Ged.
Apache::URI
Hello,
I unfortunately still don't understood the API. How can I process e.g.
the URI in a normal perl script that runs under Apache - mod_perl.
I build Apache 1.3.12 (with DSO) and mod_perl 1.22 on Linux 2.3.35.
For example my script: start-page.pl
--
use Apache::URI ();
my $uri = $r-parsed_uri;
system("echo $uri /tmp/uri_test");
--
The index.html has a form action="start-page.pl" ../form. I want
draw out the userinfo of the URI. The access method is basic with
.htaccess.
Next: How can I break a session from sever-side, so that a user who
still logged in (client Netscape) have to pass a new login procedure
with username/password, when he send a new request?
I beg your pardon if it is a simple question, but I'm new in this
technique.
Thanx in advance, Joerg.
Apache::URI doesn't work for me
Hello, I do the following: my $parsed_uri = $r-parsed_uri; my $r_scheme = $parsed_uri-scheme; my $r_host = $parsed_uri-hostinfo; my $r_rpath= $parsed_uri-rpath; my $r_path = $parsed_uri-path; The result is that the scalars $r_scheme and $r_host are empty, and only $r_path and $r_rpath have data in them (and the data is correct). But, if instead I do, my $me = Apache::URI-parse($r); my $r_scheme = $parsed_uri-scheme; my $r_host = $parsed_uri-hostinfo; my $r_rpath= $parsed_uri-rpath; my $r_path = $parsed_uri-path; I get valid data back for each request. What am I missing? I'm using mod_perl 1.23 and Apache 1.3.12 on Caldera LINUX if that's of any help. Thanks, Rob _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED]
Re: Apache::URI doesn't work for me
On Tue, 16 May 2000, Rob Tanner wrote: Hello, I do the following: my $parsed_uri = $r-parsed_uri; my $r_scheme = $parsed_uri-scheme; my $r_host = $parsed_uri-hostinfo; my $r_rpath= $parsed_uri-rpath; my $r_path = $parsed_uri-path; The result is that the scalars $r_scheme and $r_host are empty, and only $r_path and $r_rpath have data in them (and the data is correct). that's because $r-parsed_uri is the parse uri from the http request, which does not contain scheme/hostname/port, unless the request is a proxy request. But, if instead I do, my $me = Apache::URI-parse($r); that's a shortcut for building "self urls", if you don't specify a url, the Apache::URI is filled in with everything it can dig out of the request object (including scheme/hostname/port)
Re: Apache::URI port() problem
It works! Thanks so much!
Fred
Eric Cholet wrote:
Hello,
It seems the method unparse() of Apache::URI does not take the port
value into the result string. For example, I have:
my $uri = Apache::URI-parse($r, $r-uri);
$uri-scheme('http');
$uri-hostname($r-get_server_name);
$uri-port(8080);
$uri-query(scalar $r-args);
If I call $uri-unparse(), the string returned does not have port 8080
in it. Can anyone shed some light? Thanks.
Fred Xia
Can you try this patch?
Index: URI.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/URI.xs,v
retrieving revision 1.5
diff -b -u -u -r1.5 URI.xs
--- URI.xs 1998/11/13 03:27:52 1.5
+++ URI.xs 2000/04/10 10:57:54
@@ -183,6 +183,9 @@
CODE:
get_set_PVp(uri-uri.port_str,uri-pool);
+if (items 1) {
+uri-uri.port = (int)SvIV(ST(1));
+}
OUTPUT:
RETVAL
--
Eric
Apache::URI port() problem
Hello,
It seems the method unparse() of Apache::URI does not take the port
value into the result string. For example, I have:
my $uri = Apache::URI-parse($r, $r-uri);
$uri-scheme('http');
$uri-hostname($r-get_server_name);
$uri-port(8080);
$uri-query(scalar $r-args);
If I call $uri-unparse(), the string returned does not have port 8080
in it. Can anyone shed some light? Thanks.
Fred Xia
RE: Apache::URI port() problem
Hello,
It seems the method unparse() of Apache::URI does not take the port
value into the result string. For example, I have:
my $uri = Apache::URI-parse($r, $r-uri);
$uri-scheme('http');
$uri-hostname($r-get_server_name);
$uri-port(8080);
$uri-query(scalar $r-args);
If I call $uri-unparse(), the string returned does not have port 8080
in it. Can anyone shed some light? Thanks.
Fred Xia
Can you try this patch?
Index: URI.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/URI.xs,v
retrieving revision 1.5
diff -b -u -u -r1.5 URI.xs
--- URI.xs 1998/11/13 03:27:52 1.5
+++ URI.xs 2000/04/10 10:57:54
@@ -183,6 +183,9 @@
CODE:
get_set_PVp(uri-uri.port_str,uri-pool);
+if (items 1) {
+uri-uri.port = (int)SvIV(ST(1));
+}
OUTPUT:
RETVAL
--
Eric
Apache::URI troubles
hi all...
I found the below discussion in the archives... while Doug's
suggestion helps fill in some of the missing uri info, I still am having
trouble isolating $uri-user and $uri-password, and $uri-hostinfo in a
PerlTransHandler...
that is, given: http://foo:[EMAIL PROTECTED] I can't seem to get at the
user/pass combo, either by parsing hostinfo myself or using the user() and
password() methods. All hooks are enabled - is there something else I
should be looking for?
PerlTransHandler snippet:
use Apache::URI;
use strict;
sub handler {
my $r = shift;
my $log = $r-server-log;
my $uri = Apache::URI-parse($r);
my $user = $uri-user;
my $pass = $uri-password;
my $hostinfo = $uri-hostinfo;
$log-info("user: $user password: $pass hostinfo: $hostinfo");
}
both $user and $pass are blank, while $hostinfo contains www.baz.com. Any
ideas why user:pass are not part of the request object?
--Geoff
Subject: Re: Apache::URI
Author: Doug MacEachern [EMAIL PROTECTED]
Date: Thu, 23 Sep 1999 12:49:07 -0700 (PDT)
On Thu, 23 Sep 1999, Clinton Gormley wrote:
For a URL like this :
https://www.domain.com:443/exec/cellar
Apache only sees /exec/cellar in the uri, unless it's a proxy request.
you can build the complete URI, see chapter 9, also on www.modperl.com:
If the URI argument is omitted, the Iparse() method will construct a
fully qualified URI from B$r object, including the scheme, hostname,
port, path and query string. Example:
my $self_uri = Apache::URI-parse($r);
-Doug
Subject: Apache::URI
Author: Clinton Gormley [EMAIL PROTECTED]
Date: Thu, 23 Sep 1999 19:38:16 +0100
What am I doing wrong here?
use Apache::URI();
my $uri = $r-parsed_uri;
warn "Fragment ".$uri-fragment;
warn "hostinfo ".$uri-hostinfo;
warn "path_info ".$uri-path_info;
warn "port ".$uri-port;
warn "rpath ".$uri-rpath;
warn "scheme ".$uri-scheme;
warn "user ".$uri-user;
warn "unparse ".$uri-unparse;
For a URL like this :
https://www.domain.com:443/exec/cellar
gives me this :
Fragment at /apache/lib/perl/Apache/Exec.pm line 67.
hostinfo at /apache/lib/perl/Apache/Exec.pm line 68.
path_info /cellar at /apache/lib/perl/Apache/Exec.pm line 69.
port at /apache/lib/perl/Apache/Exec.pm line 70.
rpath /exec at /apache/lib/perl/Apache/Exec.pm line 71.
scheme at /apache/lib/perl/Apache/Exec.pm line 72.
user at /apache/lib/perl/Apache/Exec.pm line 73.
unparse /exec/cellar at /apache/lib/perl/Apache/Exec.pm line 74.
So it leaves out scheme, hostinfo and port. Why? Any ideas?
Thanks
Clint
Apache::URI choking
I am getting the following error when trying to
use Apache::URI
---
[Thu Dec 16 11:52:28 1999] [error] Apache::WebSQL: `Can't locate loadable object for
module Apache::URI in @INC (@INC contains: . /sysdev/web/apache/lib
/usr/local/lib/perl5/sun4-solaris/5.00404 /usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/sun4-solaris /usr/local/lib/perl5/site_perl
/sysdev/web/apache/ /sysdev/web/apache/lib/perl) at
/usr/local/lib/perl5/site_perl/mod_perl.pm line 16
---
here are the lines in mod_perl.pm causing problems
---
14 if ($ENV{MOD_PERL}) {
15 (defined {$class.'::bootstrap'} ?
16 \{$class.'::bootstrap'} :
17 \DynaLoader::bootstrap)-
18 ($class, $version);
19 }
---
Any ideas?
Thanks very much for any help!
Joe
--
Joseph Ryan
Programmer
National Human Genome Research Institute
