Ofer Inbar wrote:
>
> Michael Dearman <[EMAIL PROTECTED]> wrote:
> > I've come close to figuring this one out buy following some of the
> > questions I've seen here. But...
> >
> > Hello $ENV{REMOTE_HOST}
> >
-schnip-
> normally gets out of the environment. Remember, mod_perl is not CGI
> (al
Michael Dearman <[EMAIL PROTECTED]> wrote:
> I've come close to figuring this one out buy following some of the
> questions I've seen here. But...
>
> Hello $ENV{REMOTE_HOST}
>
> The remote host doesn't show. Printing out the %ENV, it tain't there.
> But where does Perl get it. From CGI.pm (whic
Greetings list,
Installed fresh downloads of
Apache 1.3.9 and mod_perl 1.21
But using the Perl 5.005003 that was installed with the
SuSE 6.2
mod_hello.c
when 'make', get:
:50:'hello_handlers' undeclared here (not in a function)
:50:initializer element for 'hello_module.handlers is not constant
Hello everyone...
I've recently gotten the bug to get ptkdb working with my mod_perl
setup. I've refered to the section on this in Stas' mod_perl guide
and that certainly got me places, but as it stands, things are mightly
flakey.
Here's what I've got going on...
=
Have you looked at "Perl Cookbook"? It has nice discussion on prefork
server.
you can customize it according to your requirement.
e.g.
You can control exactly how many DB connection you want(background processes
which keep persistance connection to database). You can move this to another
server i
On Tue, 30 Nov 1999, Tim Bunce wrote:
> You're quite right, but both cases need to be allowed for as some
> database (notably Oracle) get upset if a child process tries to use a
> connection established by the parent process.
Interesting. So Oracle snoops on the PID of the process calling it?
On Mon, Nov 29, 1999 at 07:46:50PM -0500, Sam Tregar wrote:
> On Mon, 29 Nov 1999, Tim Bunce wrote:
>
> > Ignoring 'thread' (unsafe for production use) and 'debug' modes, the
> > normal 'fork' mode means that each client gets a seperate ProxyServer
> > process. And because of that, clients have n
On Mon, 29 Nov 1999, Tim Bunce wrote:
> Ignoring 'thread' (unsafe for production use) and 'debug' modes, the
> normal 'fork' mode means that each client gets a seperate ProxyServer
> process. And because of that, clients have no way to share connections
> with each other.
Is that necessarily the
> "Tim" == Tim Bunce <[EMAIL PROTECTED]> writes:
Tim> I hope that helps.
Immensely!
Thank you, Tim!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comed
On Mon, Nov 29, 1999 at 01:19:53PM -0800, Randal L. Schwartz wrote:
>
> [watch the followups... this is going to both the modperl
> and the DBI list...]
>
> > "Ed" == Ed Park <[EMAIL PROTECTED]> writes:
>
> Ed> each creates a network connection to DBI::ProxyServer, which
> Ed> creates a few
> So, Tim, what *are* the differences, and when should we should we
> choose Apache::DBI vs DBI->connect_cached, and why?
I think one of the big differences is that Apache::DBI overrides the
disconnect method, to prevent accidentally calling disconnect from a
mod_perl script. When using connect_
[watch the followups... this is going to both the modperl
and the DBI list...]
> "Ed" == Ed Park <[EMAIL PROTECTED]> writes:
Ed> each creates a network connection to DBI::ProxyServer, which
Ed> creates a few persistent connections to the db server using the
Ed> connect_cached method.
I had
>
> The following testcast fails under 1.20. Basically, if there is a hash
> deref inside an HREF tag, without quotes, you get the following error:
>
> [27723]ERR: 13: Line 4: Missing right +]
>
> If you quote the HREF or create a temporary variable to hold the
> hash deref
> everything works fin
>
> I've sent this to this list already once before so I apologize
> for resubmitting
> this problem.
>
And here is what I have answered you, looks like you didn't get that (at
least you didn't replied that it isn't working):
> Note: The display_errors_as_html method doesn't send out any header
> What the HTML spec does not require is for the HEAD section to come
> first. So if you must include the HEAD section at the end of the
> document, that would be fine.
That's incorrect, the standard does indeed require the HEAD section to
preceed the BODY.
In http://www.w3.org/TR/REC-html40/s
> I know this problem. As you write above, writing
>
> Link
>
> will solve the problem. Because parser tries to find the end of the HREF
arg
> and if not quoted the end is after the first space or when he finds a >.
> Because the quoting doesn't hurt (as far as I see) I haven't changed this
> unti
On Mon, 29 Nov 1999, Oleg Bartunov wrote:
> Hi,
>
> I'm using mod_perl, DBI, ApacheDBI and was quite happy
> with persistent connections httpd<->postgres until I used
> just one database. Currently I have 20 apache servers which
> handle 20 connections to database. If I want to work with
> anothe
>
> Is this, or will this be, documented somewhere?
I don't think so :-(
> Seeing as it is a kludge,
> even if it does help performance somewhat, is this going to be
> fixed in the
> future or is this Working As Designed? Any chance of having the "end of
> tag" logic changed to ignore character
According to Oleg Bartunov:
> > > Currently I have 20 apache servers which
> > > handle 20 connections to database. If I want to work with
> > > another database I have to create another 20 connections
> > > with DB, so I will have 40 postgres backends. This is too much.
>
> I didn't write all de
Oleg--
I don't know that this will help, but you could try using DBI::Proxy. The
setup would theoretically be as follows: each apache process uses DBI::Proxy
as the client; each creates a network connection to DBI::ProxyServer, which
creates a few persistent connections to the db server using th
On Mon, 29 Nov 1999, Robin Berjon wrote:
> I'm unsure that even parsing the request will get you
> that. A grep through my logs shows no trace of the
> fragment ever being present, while a lot of pages
> containing some appear. It wouldn't surprise me totally
> if the browser kept the fragment to
I've sent this to this list already once before so I apologize for resubmitting
this problem.
This application works fine so long as there are no errors. If there are validation
errors what is suppose to happen is the errors are to be displayed at the top of the
HTML doc followed by the for
The following testcast fails under 1.20. Basically, if there is a hash
deref inside an HREF tag, without quotes, you get the following error:
[27723]ERR: 13: Line 4: Missing right +]
If you quote the HREF or create a temporary variable to hold the hash deref
everything works fine.
What follows
At 10:04 29/11/1999 -0800, brian moseley wrote:
>it appears that neither $r->uri nor $r->parsed_uri retain
>any knowledge of the fragment.
>
>is there any way for me to retrieve the fragment info short
>of parsing $r->the_request?
I'm unsure that even parsing the request will get you that. A grep
> "Andrei" == Andrei A Voropaev <[EMAIL PROTECTED]> writes:
Andrei> Correct too. Though Apache::URI::fragment() is present and
Andrei> even documented :) Probably because some browsers pass this
Andrei> fragment to the server?
No, because a server could pass *back* a URI with a fragment in
g
Correct too. Though Apache::URI::fragment() is present and even documented :)
Probably because some browsers pass this fragment to the server?
Andrei
On Mon, Nov 29, 1999 at 10:16:04AM -0800, Randal L. Schwartz wrote:
> > "brian" == brian moseley <[EMAIL PROTECTED]> writes:
>
> brian> im re
I've had the same problem. There's a mistake in the Eagle book when it
states that $r->the_request() eq join(' ', $r->method, $r->uri,
$r->protocol).
Proper way to access fragment as well as query_string is to use
my $uri = $r->parsed_uri();
my $fragment = $uri->fragment();
Andrei
On Mon, Nov 2
> "brian" == brian moseley <[EMAIL PROTECTED]> writes:
brian> im requesting the url
brian> http://www.maz.org/foo/index.html#perl
brian> it appears that neither $r->uri nor $r->parsed_uri retain
brian> any knowledge of the fragment. they both return
brian> /foo/index.html
brian> is th
maybe $r->path_info is what you are after?
--Geoff
> -Original Message-
> From: brian moseley [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, November 29, 1999 1:04 PM
> To: [EMAIL PROTECTED]
> Subject: fragment in $r->uri
>
>
> im requesting the url
>
> http://www.maz.org/foo/index
> "JB" == Jeffrey Baker <[EMAIL PROTECTED]> writes:
JB> Vivek Khera wrote:
>>
>> > "SM" == Shay Mandel <[EMAIL PROTECTED]> writes:
>>
SM> p.s. - the header file I'm getting is the same for all the pages, thus
SM> it does not resides in the same directory as the page itself.
>>
>> Conve
im requesting the url
http://www.maz.org/foo/index.html#perl
it appears that neither $r->uri nor $r->parsed_uri retain
any knowledge of the fragment. they both return
/foo/index.html
is there any way for me to retrieve the fragment info short
of parsing $r->the_request?
Vivek Khera wrote:
>
> > "SM" == Shay Mandel <[EMAIL PROTECTED]> writes:
>
> SM> p.s. - the header file I'm getting is the same for all the pages, thus
> SM> it does not resides in the same directory as the page itself.
>
> Conveniently, Netscape recognizes the html tag anywhere in the
> d
> "OB" == Oleg Bartunov <[EMAIL PROTECTED]> writes:
OB> This message is for every proxied request.
OB> Does anybody knows what does it means ?
OB> In proxy config I have
OB> ProxyReceiveBufferSize 1048576
OB> Restarting proxy server doesn't helps.
OB> btw, anybody know what is an optimal s
> "SM" == Shay Mandel <[EMAIL PROTECTED]> writes:
SM> p.s. - the header file I'm getting is the same for all the pages, thus
SM> it does not resides in the same directory as the page itself.
Conveniently, Netscape recognizes the html tag anywhere in the
document, not just in the section.
When a browser claims that it supports HTTP/1.1 it doesn't mean that
it uses it for each request. I believe that in general case browser
always uses HTTP/1.0 which is logged in apache log.
I'm not sure how to make the same browser to use HTTP/1.1 as default
protocol. I guess you shouldn't because
On Mon, 29 Nov 1999, Sheth, Niraj wrote:
> Date: Mon, 29 Nov 1999 11:19:12 -0500
> From: "Sheth, Niraj " <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: pool of DB connections ?
>
> Have you looked at "Perl Cookbook"? It has nice discussion on prefork
> server
On Mon, 29 Nov 1999, Leslie Mikesell wrote:
> Date: Mon, 29 Nov 1999 09:59:38 -0600 (CST)
> From: Leslie Mikesell <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: pool of DB connections ?
>
> According to Oleg Bartunov:
>
> > I'm using mod_perl,
Hi,
I've checked the archive and not found anything relevant, and I've
looked through the mod_perl docs, but it's all aimed at people who want
to write their own modules.
I'm using: Apache 1.3.9, mod_perl 1.21, Apache::DBILogger-0.93,
Apache::DBILogConfig-0.01, MySQL 3.22.27
I wonder if some ki
This has tripped me up in the past as well.
While the preponderance of browsers support HTTP/1.1 features, they use
the lowest common denominator language, HTTP/1.0, to make requests.
Language extensions are permitted but it's all for the best that these
user agents don't report themselves as HTT
Pouneh Mortazavi wrote:
>
> OK. so this is unrelated to the modperl mailing list. but its an
> interesting question. If you know anywhere else I could post this,
> please tell me.
>
> I'm trying to find out how many clients support HTTP 1.1 features such as
> keepalives and domain-name based vir
According to Oleg Bartunov:
> I'm using mod_perl, DBI, ApacheDBI and was quite happy
> with persistent connections httpd<->postgres until I used
> just one database. Currently I have 20 apache servers which
> handle 20 connections to database. If I want to work with
> another database I have to c
hi,
I'm back on track, trying to debugf this beast.
- Modperl is compiled _statically_ into apache.
- DBI::mysql works great from CGI scripts.
- There seem to be no user problems: the user the script runs
under is allowed full control on /tmp, so it should be able
Hi,
I'm using mod_perl, DBI, ApacheDBI and was quite happy
with persistent connections httpd<->postgres until I used
just one database. Currently I have 20 apache servers which
handle 20 connections to database. If I want to work with
another database I have to create another 20 connections
with
> >This message is for every proxied request.
> >Does anybody knows what does it means ?
> >In proxy config I have
> >ProxyReceiveBufferSize 1048576
> >
> >Restarting proxy server doesn't helps.
>
> Are you sure you are getting this message on absolutely every proxy request ?
>
> Maybe 1048576
Hi,
I was running into a similar problem (Apache 1.3.9, mod_perl 1.21, PHP
3.0.12). Apache compiled with mod_perl (same source tree) so I figured it
was PHP. I tried 3.0.11, and it compiled beautifully. Not sure what the issue
actually was, but it did work.
Try php-3.0.11 rather than php-3.0.12
45 matches
Mail list logo
