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: 23891
Status: rejected
Priority: 0/
Queue: CGI
People
Owner: MARKSTOS [...] cpan.org
Requestors: salomaki [...] stanford.edu
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Dec 11 17:23:34 2006 salomaki [...] stanford.edu - Ticket created
Subject: url() and self_url() act inconsistently for Server Side Includes
Date: Mon, 11 Dec 2006 14:23:03 -0800
To: bug-CGI.pm [...] rt.cpan.org
From: Brian Salomaki <salomaki [...] stanford.edu>
I am including a Perl script within an HTML page using Apache's <!--#include virtual="script.pl" --> syntax and trying to use this script to generate a form that will then be sent back to the same HTML page for processing. It seems like the straightforward solution would be to use CGI::self_url(), but this doesn't always work. I was first running my script over HTTPS and it worked fine, generating a URL such as "https://server/page.html". When switching to using normal HTTP, the output of self_url() ends up being something like "included://server/page.html", which is not a useful/valid URL. Digging into the code a little bit, I see that this is coming from the method "protocol()" which will return HTTPS for requests over port 443, but otherwise return the environment variable SERVER_PROTOCOL. When using Server-Side Includes, SERVER_PROTOCOL gets set to INCLUDED, hence the resulting URL. I could hack a fix for now and replace "included://" with "http://" after generating the URL, but it seems like CGI.pm should take a stand one way or the other and either always generate valid URLs (preferable), or always say "included" when the script is included, even if it's included from a page that uses HTTPS.
  Wed Jul 22 21:11:39 2009 MARKSTOS [...] cpan.org - Taken
  Wed Jul 22 21:18:07 2009 MARKSTOS [...] cpan.org - Correspondence added
On Mon Dec 11 17:23:34 2006, salomaki@stanford.edu wrote: Show quoted text
> I am including a Perl script within an HTML page using Apache's > <!--#include virtual="script.pl" --> syntax and trying to use this > script to generate a form that will then be sent back to the same HTML > page for processing. > > It seems like the straightforward solution would be to use > CGI::self_url(), but this doesn't always work. I was first running my > script over HTTPS and it worked fine, generating a URL such as > "https://server/page.html". When switching to using normal HTTP, the > output of self_url() ends up being something like > "included://server/page.html", which is not a useful/valid URL. > > Digging into the code a little bit, I see that this is coming from the > method "protocol()" which will return HTTPS for requests over port 443, > but otherwise return the environment variable SERVER_PROTOCOL. When > using Server-Side Includes, SERVER_PROTOCOL gets set to INCLUDED, hence > the resulting URL. > > I could hack a fix for now and replace "included://" with "http://" > after generating the URL, but it seems like CGI.pm should take a stand > one way or the other and either always generate valid URLs (preferable), > or always say "included" when the script is included, even if it's > included from a page that uses HTTPS.
Thanks for the report. As you've seen, there's some complexity to this situation. On the one hand, CGI.pm is trying hard to get https detection right, checking for port "443" if the normal https() detection doesn't catch it. I think I'm OK with that and am not inclined to change it, even though it's perhaps not ideal for the https/included edge case. On the other hand, CGI.pm trusts the server to give a correct protocol name, and I don't mind that it simply reports back what the server tells it here, even if is non-standard like "included://". In conclusion, although there's some inconsistency here, I'm in favor of leaving this part of code as-is right now. I'm tentatively marking this change request as "rejected" although I'm open to discussing a specific counter-propoosal if you have one. Mark
  Wed Jul 22 21:18:07 2009 The RT System itself - Status changed from 'new' to 'open'
  Wed Jul 22 21:18:09 2009 MARKSTOS [...] cpan.org - Status changed from 'open' to 'rejected'
  Fri May 23 14:28:16 2014 The RT System itself - Queue changed from CGI.pm to CGI