Location problem

[Ron Spears]

Hello,

Is there a simple way to pass a variable from a Perl script to a HTML
page using a location redirect?


print $loc = "Location:http://www.website.com/confirm.htm\n";
print "$loc\n\n";

What I want is something like this, but it doesn't work:

print $loc = "Location:http://www.website.com/confirm.htm?passed_variable\n";
print "$loc\n\n";

 

[Erich Musick]

Yeah - that's why it doesn't work.

Try:

my $loc = "Location: http://www.website.com/confirm.htm?passed_variable";
print "$loc\n\n";

 

[Alan J. Flavell]

"For some reason"...? I think you need to go read up on how HTTP headers
work...

From the context, I understood the question to be about a CGI
response, rather than a raw HTTP transaction response.

They're very similar, of course, by design; but there are subtle
differences, so I'd have to recommend keeping the concepts distinct on
one's mind.

Of course, this has nothing specifically to do with Perl.

But as perlport points out, the correct portable terminator for
interworking sockets (and this goes for HTTP) would be \015\012 (i.e
CRLF) written in binary mode.

For CGI, however, where the process is communicating with the web
server (httpd) on the _same_ platform, the platform-specific newline
representation, i.e \n , is considered appropriate. And that's what
we saw being used in this presumed-CGI context, so that detail was OK
(the problem lay elsewhere, as I said before).

So that at least manages to drag _some_ Perl relevance into the
thread, even if this particular issue doesn't answer the questioner's
problem ;-)

cheers

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From the context, I understood the question to be about a CGI
response, rather than a raw HTTP transaction response.

They're very similar, of course, by design; but there are subtle
differences, so I'd have to recommend keeping the concepts distinct on
one's mind.

Of course, this has nothing specifically to do with Perl.

But as perlport points out, the correct portable terminator for
interworking sockets (and this goes for HTTP) would be \015\012 (i.e
CRLF) written in binary mode.

For CGI, however, where the process is communicating with the web
server (httpd) on the _same_ platform, the platform-specific newline
representation, i.e \n , is considered appropriate. And that's what
we saw being used in this presumed-CGI context, so that detail was OK
(the problem lay elsewhere, as I said before).

So that at least manages to drag _some_ Perl relevance into the
thread, even if this particular issue doesn't answer the questioner's
problem ;-)

CRLF vs LF is not the OP's problem.

The OP wrote:

# For some reason in this sendmail routine, if I position
# this line after a particular line in the sendmail rountine, print
# "Content-type: text/html\n\n"; it causes the redirect to print out as
# html on the screen only...

where "this line" means the "Location: http://..." line.

A CGI program's output consists of HTTP headers followed by content. The
headers are separated from the content by a pair of newlines (a pair of
CRLF pairs, strictly speaking). The OP clearly output a Content-type
HTTP header, followed by a pair of newlines which ends the header set.
No wonder the "Location" header was displayed on the browser screen as
content instead of being used by the server or browser for redirection.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPzaa42PeouIeTNHoEQKxkACgrEbcGns974PdOY47kvUF0OCkXVsAoKqz
RhIGVMiZuXAa8IEsJGczGdvv
=Q4GU
-----END PGP SIGNATURE-----

 

[Alan J. Flavell]

On Sun, Aug 10, Eric J. Roode inscribed on the eternal scroll:

[..comprehensive quote now snipped..]

CRLF vs LF is not the OP's problem.

As I had said in my followup earlier in the thread, indeed.

A CGI program's output consists of HTTP headers followed by content.

Excuse me, but as I already said: a CGI program's output consists of
a proper CGI response:

They're very similar, of course, by design; but there are subtle
differences, so I'd have to recommend keeping the concepts distinct

The

[CGI]
headers are separated from the content by a pair of newlines
Yes

(a pair of CRLF pairs, strictly speaking).

No. See the CGI specification. The clue was in my posting which -
for whatever reason - you are contradicting.

The OP clearly output a Content-type HTTP header,

The posting had said:

|| Content-type: text/html\n\n

(it was a *CGI* header, and it used the appropriate "\n" newlines, as
I had pointed out but you then contradicted.)

followed by a pair of newlines which ends the header set.

Indeed. I thought we'd all be able to agree about that, and that it
wasn't a Perl problem. That's why two separate postings redirected
the questioner to the CGI authoring group, along with a brief note of
their problem.

No wonder the "Location" header was displayed on the browser screen

Quite. I felt I had already dealt with that, and in my later f'up was
only dealing with a detail of your posting on the thread.

best regards