On Tue, Apr 22, 2008 at 1:32 PM, Julian Dobson <[EMAIL PROTECTED]> wrote:
> I am using Apache/2.2.3 with a PerlTransHandler in which I decline CGI
> scripts. However, the CGI script isn't getting the data using CGI::Minimal
> (or any other version of CGI I care to try).
Are you reading the POST d
John ORourke wrote:
Hi folks,
The underlying reason for this is that I have a reverse proxy in front
of it, which proxies HTTP and HTTPS requests. The back-end needs to
create self-referencing URLs but cannot tell if it's HTTP or HTTPS, so I
decided to direct HTTP to port 81 and HTTPS to por
This is driving me nuts!
I am using Apache/2.2.3 with a PerlTransHandler in which I decline CGI
scripts. However, the CGI script isn't getting the data using
CGI::Minimal (or any other version of CGI I care to try). If I use GET,
this isn't an issue, and an old install (Apache/1.3.27) running
On Apr 23, 2008, at 11:53, David E. Wheeler wrote:
I was fiddling with that yesterday, and $r->main seemed to return
true every time. But I'll try again.
The /101/ request *is* a subrequest? WTF is that coming from? It
seems to happen after the AccessHandler finishes, but before the
Respo
On Apr 23, 2008, at 11:19, David E. Wheeler wrote:
On Apr 23, 2008, at 11:16, Torsten Foertsch wrote:
I think the /101 request is a subrequest. Do you use path_info?
This together
with the perl-script handler can cause a subrequest when apache
wants to
translate PATH_INFO to PATH_INFO_TRANS
On Apr 23, 2008, at 11:16, Torsten Foertsch wrote:
I think the /101 request is a subrequest. Do you use path_info? This
together
with the perl-script handler can cause a subrequest when apache
wants to
translate PATH_INFO to PATH_INFO_TRANSLATED. You can distinguish
between a
subrequest an
On Apr 23, 2008, at 11:09, Geoffrey Young wrote:
cleanup handlers are just callbacks run when a memory pool goes out
of scope.
Oh. And here I thought that they ran when the request completed.
your test suggests that the memory pool allocated for the request is
going out of scope before the
On Wed 23 Apr 2008, David E. Wheeler wrote:
> I'm busy finalizing the port of Bricolage to mod_perl2. In the
> process, I've discovered a bit of weirdness with our TransHandler. For
> certain requests, it seems to execute twice. Under mod_perl1, here's
> an example:
>
> 75947 Apache=SCALAR(0x
Under mod_perl2, however, the same request looks like this:
75749 Apache2::RequestRec=SCALAR(0x29f3300) TransHandler start for
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR(0x29f3300) TransHandler finish for
/workflow/profile/desk/101/101/
75749 Apache2::RequestRec=SCALAR
Howdy,
I'm busy finalizing the port of Bricolage to mod_perl2. In the
process, I've discovered a bit of weirdness with our TransHandler. For
certain requests, it seems to execute twice. Under mod_perl1, here's
an example:
75947 Apache=SCALAR(0x295ed70) TransHandler start for /workflow/
p
On Mon 21 Apr 2008, J Amuse wrote:
> I wrote a simple module that parses the HTTP response body and updates
> certain text. I want the script to be able to parse and manipulate the HTTP
> response headers as well. For example add secure and HttpOnly flags to
> certain cookies, or add a redirection
On Mon, Apr 21, 2008 at 4:30 PM, J Amuse <[EMAIL PROTECTED]> wrote:
> when using f->read it appears as though the HTTP headers are not including.
> I know err_headers_out should have access to the headers, but is there a way
> to force f->read to access the HTTP headers as well?
No, the headers ar
Many, many thanks for the input everyone - naturally it turned out to be
a case of RTFM but here's a summary of the simplest ways to do it. I've
no idea how I missed these in the docs, though I am at the
bang-head-on-wall stage of development.
(I'm going on the assumption that the proxy may n
Philippe M. Chiasson <[EMAIL PROTECTED]> [21-04-2008 09:16]:
> Fred Moyer wrote:
>> Geoffrey Young wrote:
[...]
>>> so I guess this means a mp2 release should (going forward) include _and_
>>> imply a new release of
>>> o mp2
>>> o Apache-Test
>>> o Apache-Reload
> o Apache-SizeLimit
>
On Wed 23 Apr 2008, John ORourke wrote:
> The underlying reason for this is that I have a reverse proxy in front
> of it, which proxies HTTP and HTTPS requests. The back-end needs to
> create self-referencing URLs but cannot tell if it's HTTP or HTTPS, so I
> decided to direct HTTP to port 81 and
André Warnier wrote:
André Warnier wrote:
John ORourke wrote:
Hi folks,
I can't seem to find a way to retrieve the inbound port number during
requests.
I have a server listening on multiple ports, and need to know which
one the request came in on. Here's the setup:
apache config:
Hi John
> The underlying reason for this is that I have a reverse proxy in
> front
> of it, which proxies HTTP and HTTPS requests. The back-end needs to
> create self-referencing URLs but cannot tell if it's HTTP or HTTPS, so I
> decided to direct HTTP to port 81 and HTTPS to port 82. I'd pre
André Warnier wrote:
John ORourke wrote:
Hi folks,
I can't seem to find a way to retrieve the inbound port number during
requests.
I have a server listening on multiple ports, and need to know which
one the request came in on. Here's the setup:
apache config:
Listen 127.0.0.1:81
John ORourke wrote:
Hi folks,
I can't seem to find a way to retrieve the inbound port number during
requests.
I have a server listening on multiple ports, and need to know which one
the request came in on. Here's the setup:
apache config:
Listen 127.0.0.1:81
Listen 127.0.0.1:82
I wrote a simple module that parses the HTTP response body and updates
certain text. I want the script to be able to parse and manipulate the HTTP
response headers as well. For example add secure and HttpOnly flags to
certain cookies, or add a redirection when a 500 error code is returned. The
code
Hi folks,
I can't seem to find a way to retrieve the inbound port number during
requests.
I have a server listening on multiple ports, and need to know which one
the request came in on. Here's the setup:
apache config:
Listen 127.0.0.1:81
Listen 127.0.0.1:82
NameVirtualHost *:*
21 matches
Mail list logo
