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)

History Show all quoted text
  Thu May 27 00:10:00 2010 MRDVT [...] cpan.org - Ticket created
Subject: CGI.pm protocol mehtod broken for reverse proxy running 443=>80
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
  Thu May 27 00:46:07 2010 MRDVT [...] cpan.org - Status changed from 'new' to 'open'
  Thu May 27 08:34:34 2010 mark [...] summersault.com - Correspondence added
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>
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
  Sun Jun 20 02:26:07 2010 MRDVT [...] cpan.org - Correspondence added 10 min
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.
  Mon Jun 21 01:38:10 2010 MRDVT [...] cpan.org - Subject changed from 'CGI.pm protocol mehtod broken for reverse proxy running 443=>80' to 'CGI.pm protocol method broken for reverse proxy running 443=>80'
  Tue Jun 22 10:30:50 2010 MARKSTOS [...] cpan.org - Status changed from 'open' to 'rejected'
  Fri May 23 14:28:19 2014 The RT System itself - Queue changed from CGI.pm to CGI