Malcolm J Harwood <[EMAIL PROTECTED]> writes:
[...]
> The current doc says:
> # parse RFC822-complient date string
>
> Which it doesn't (as RFC822 includes multiple timezones).
Which is *exactly* why I recommended the docs include a pointer to
aprutil. All modperl does it wrap the C func
On Wednesday 16 March 2005 10:19 pm, Joe Schaefer wrote:
> > What should the manpage say? something like the following?
> >The function assumes GMT, regardless of the used timezone,
> >according to RFC 2616 Section 3.3 requires.
> No need to mention the RFC; how about this?
The current do
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
What should the manpage say? something like the following?
The function assumes GMT, regardless of the used timezone,
according to RFC 2616 Section 3.3 requires.
No need to mention the RFC; how about this?
APR::Date::parse_
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> What should the manpage say? something like the following?
>
>The function assumes GMT, regardless of the used timezone,
>according to RFC 2616 Section 3.3 requires.
No need to mention the RFC; how about this?
APR::Date::parse_http is
Nick *** wrote:
As I wrote in a previous mail, there is another error with the MP_STATIC_EXTS=1
option. When running make, the process dies with:
cp Base64.pm ../../../blib/lib/APR/Base64.pm
make[3]: *** No rule to make target
`../../../blib/arch/auto/APR/Base64/Base64.so', needed by `dynamic'.
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Malcolm J Harwood wrote:
According to the docs, APR::Date::http parses the format:
Sun, 06 Nov 1994 08:49:37 GMT
as per RFC 822.
However it does not seem to parse
Sun, 06 Nov 1994 08:49:37 EST
correctly. It assumes it's GM
Actually, we solved the issue soon after this post (which took quite a while
to make it to the list) ... anyhow, we developed a compiled language
interface to our databases that does simple queries and in some cases data
comparison, and returns the results to the aforementioned perl object
crea
Dominique Quatravaux wrote:
In which case you will end up with use warnings on the same line as the
shebang line, no? which will look strange in the debugger
Actually I find this pretty idiomatic, look:
use warnings; #!/usr/bin/perl -w
No? :-)
It may confuse some users who may claim that mod_
Anders Nielsen wrote:
We are using a setup with a "light-weight" apache in front of the
mod_perl server.
Lately we have seen some problems with the mod_perl server. From time to
time it stops responding to the requests from the front end. The problem
seems to be related to the mod_perl server only
Tom Schindl wrote:
jet wrote:
i'm losing my mind here;
to protect the client, i am 're-naming' the module names for
confidentiality, but I have a seriously weird problem that is not
adding up to anything intuitive for me at all.
We have a foundation module that deals with interacting with our
d
On Wed, 2005-03-16 at 19:30 -0500, jonathan vanasco wrote:
> just wanted to clarify - i said that it was closer to the speed of bdb
> than mysql -- not faster than bdb
In my tests, it's a lot slower than MySQL. I'm doing 50% writes in this
test though, so it may be a poor benchmark.
I'm not try
I just saw perrin's post on perlmonks -- can't remember my login/pass
for there
just wanted to clarify - i said that it was closer to the speed of bdb
than mysql -- not faster than bdb
most of my tests have been with selects though -- i routinely use it as
a way to store/retrieve certain types
jet wrote:
i'm losing my mind here;
to protect the client, i am 're-naming' the module names for
confidentiality, but I have a seriously weird problem that is not
adding up to anything intuitive for me at all.
We have a foundation module that deals with interacting with our
databases... higher
i'm losing my mind here;
to protect the client, i am 're-naming' the module names for
confidentiality, but I have a seriously weird problem that is not adding up
to anything intuitive for me at all.
We have a foundation module that deals with interacting with our
databases... higher level modul
I need some help with a hard-to-locate (for me) bug. After some major
upgrades of OS, perl, apache, etc a mod_perl app that worked fine
before began complaining that "You have an error in your SQL syntax". I
found it was due to incorrect quoting based on incorrect mysql column
types returned by
Answering my own question ...
On Mar 16, 2005, at 8:08 AM, I wrote:
I need some help with a hard-to-locate (for me) bug. After some major
upgrades of OS, perl, apache, etc a mod_perl app that worked fine
before began complaining that "You have an error in your SQL syntax".
I found it was due to
On Wed, 2005-03-16 at 17:51 +0530, Joshua N Pritikin wrote:
> Now I'm getting a different error:
>
>'.cgi_error' => '500 Bad read on multipart/form-data! wanted 880, got
> 0',
Ah, I see.
Careful examination of CGI.pm suggests that STDIN no longer works for
POST data.
I changed all the sysre
Maxim Nechaev <[EMAIL PROTECTED]> writes:
> Scott, thanks for response!
>
> SG> The main Apache process runs as root, and each Apache child process
> SG> runs as a less-privileged user, and so would not have permission to
> SG> signal the main process to tell it to reload.
>
> Ok i understand diff
There's also a great tool by Microsoft[1] (now there's an oxymoron for
you :-)) called Fiddler[2] which is basically a proxy server that sits
on your local machine and lets you inspect all the HTTP traffic (as well
as build your own requests). The only major drawback is that since it's
a separate
Hi Tony,
I'm still using Naviscope for this, it small, fast and works with any Browser (
with proxy support ).
By the way, has someone any ideas what happened to the company which was
building naviscope?
Denis
-Ursprüngliche Nachricht-
Von: Tony Clayton [mailto:[EMAIL PROTECTED]
Gese
This is off-topic for this list, but I thought I'd just mention for those that
are troubleshooting HTTP issues, there are useful plugins for both IE and
Firefox that show you both incoming and outgoing HTTP headers, including through
https connections.
For IE, there is an IE Explorer Bar add-on ca
(sorry if this shows up twice, yesterday I attempted a post without
being subscribed)
I need some help with a hard-to-locate (for me) bug. After some major
upgrades of OS, perl, apache, etc a mod_perl app that worked fine
before began complaining that "You have an error in your SQL syntax". I
On Wed, 2005-03-16 at 11:24 +0530, Joshua N Pritikin wrote:
> I'm trying to get parameters from multipart/form-data.
D'oh! I was passing the request object into CGI::Simple.
CGI::Simple->new($r);
I guess I should pass in nothing, e.g.:
CGI::Simple->new();
Now I'm getting a different error
I would like to add that no messages are seen in the error logs. We are
using Apache/1.3.29 and mod_perl/1.29 on Redhat linux.
mvh
Anders Nielsen
We are using a setup with a "light-weight" apache in front of the
mod_perl server.
Lately we have seen some problems with the mod_perl server. From time to
time it stops responding to the requests from the front end. The problem
seems to be related to the mod_perl server only since wget-ing on the
> In which case you will end up with use warnings on the same line as the
> shebang line, no? which will look strange in the debugger
Actually I find this pretty idiomatic, look:
use warnings; #!/usr/bin/perl -w
No? :-) Besides this line is seldom debugged anyway (at least in my
experience)
Scott, thanks for response!
SG> The main Apache process runs as root, and each Apache child process
SG> runs as a less-privileged user, and so would not have permission to
SG> signal the main process to tell it to reload.
Ok i understand difficulty.
Maybe exists a way to force apache reread or c
27 matches
Mail list logo
