Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 57892
Status: rejected
Worked: 10 min
Priority: 0/
Queue: CGI

People
Owner: Nobody in particular
Requestors: MRDVT [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: CGI.pm protocol mehtod broken for reverse proxy running 443=>80
Download (untitled) / with headers
text/plain 892b
My configuration is client => https => proxy => http => server => CGI => CGI.pm application developer => http => server => CGI => CGI.pm application From sub protocol: Show quoted text
> return 'https' if uc($self->https()) eq 'ON';
I have no '^HTTPS' environment variables Show quoted text
> return 'https' if $self->server_port == 443;
SERVER_PORT 80 Show quoted text
> my $prot = $self->server_protocol;
SERVER_PROTOCOL HTTP/1.1 The only work around I can see is to set an apache variable in the http server configuration. SetEnv HTTPS_REVERSE_PROXY ON But, this breaks the developer interface which hits the site over http. There is nothing in the environment that identifies the client is https except that the traffic is coming from the proxy which has a REMOTE_ADDR = 10.1.1.255/24 This looks like a limitation of reverse proxy more so than CGI.pm but I'm not sure CGI should "guess" wrong. Thanks, Mike mrdvt92
Subject: Re: [rt.cpan.org #57892] CGI.pm protocol mehtod broken for reverse proxy running 443=>80
Date: Thu, 27 May 2010 08:34:21 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Download (untitled) / with headers
text/plain 429b
Hello, Thanks for the report, Michael. However, it's not clear what you are reporting as being the bug in CGI.pm. If you could express the condition through a failing Test::More-style test, that would be helpful. If you are suggesting that we handle HTTPS detection differently, it would be useful if you could reference RFCs and other implementations that indicate the recommended correct or standard behavior. Mark
Download (untitled) / with headers
text/plain 670b
On Thu May 27 08:34:34 2010, mark@summersault.com wrote: Show quoted text
> If you are suggesting that we handle HTTPS detection differently, it > would be useful if you could reference RFCs and other implementations > that indicate the recommended correct or standard behavior.
I have found out that our proxy is not configured appropriately. It should do something similar to the apache directive "ProxyPassReverse /path/ https://www.server.com/path/" but I am told our proxy does not do this due to "large overhead". The work arounds that we have in place are: not to use any CGI.pm methods that build full URLs; and pass redirect headers as relative paths contrary to RFCs.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.