You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Robert Landrum <rl...@capitoladvantage.com> on 2001/02/09 00:19:58 UTC

Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

That's what the RFC says... But that's not the way that a browser 
handles it.  I don't know why browsers don't support the "standards," 
but that's not exactly the topic.

Every browser I've ever tested with, including LWP, lynx and AOL, 
have supported relative Location headers.

If the W3 wants to document it incorrectly or change the unofficial 
standard, then they are wasting their time.



Rob


>On Thu, 8 Feb 2001, Robert Landrum wrote:
>
>> If all browsers followed the W3 standards the world would be a better
>> place...
>>
>> They say "...field value consists of a single absolute URL."
>>                                                         ^^^ I think
>> they mean URI because the example says "absoluteURI", not URL.
>>
>> An absolute URI is
>>
>> /some/location
>
>No, that is not an absolute URI.  absoluteURI is defined unabiguously in
>RFC 2068:
>
>absoluteURI    = scheme ":" *( uchar | reserved )
>
>So, you see, an absoluteURI MUST contain the scheme.
>
>>
>> But so is
>>
>> http://www.somehost.com/some/location
>>
>> Both are valid URIs and both absolute.  One is more qualified than the
>> other.
>
>No.
>
>> A relative URI is
>>
>> some/location
>>
>> which is incorrect, and not what I meant in my message.
>>
>> Which brings us to the next point...
>>
>> By using relative *URLs* such as /some/location, you avoid changing
>> the location field in the browser window, which is often desired.  If
>> you use an absolute *URL*, the location field changes to the absolute
>> URL.
>
>This is the desired behavior.
>
>> You can try it with a simple perl script CGI.
>>
>> #!/usr/bin/perl print "Location: /some/location/\n\n";
>>
>> or
>>
>> #!/usr/bin/perl print "Location:
>> http://somehost.com/some/location/\n\n";
>
>-jwb


Robert L. Landrum
Senior Programmer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
UNIX was not designed to stop its users from doing stupid things,
as that would also stop them from doing clever things. --- Doug Gwyn

Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

Posted by Tony Demark <to...@legaux.com>.
Let me bring this back to mod_perl for a sec:

>If a CGI script sends out a Location: header that doesn't begin with a
>protocol (like http: or ftp:), then it's an *internal* redirect.
>
>For an internal redirect, the browser never sees the transaction.  The
>web server just does a "goto", picking up the new resource, delivering
>the content to the browser AS IF IT WAS THE OLD URL.  The browser
>doesn't even know it happened (thus the problem I said earlier about
>relative URLs in the delivered document being broken).

Just for clarification, you are speaking _specifically_ about 
non-mod_perl CGIs, correct?

Doing this (via mod_perl):

$r->header_out(Location => '/foo/bar/');

causes an external redirect (REPLY headers being sent to the browser), as in:

glory:tony[1]% telnet www.uswx.com 80
Trying 207.106.24.123...
Connected to sundog.uswx.com.
Escape character is '^]'.
GET /us/wx/PA HTTP/1.0

HTTP/1.0 302 Found
Date: Fri, 09 Feb 2001 14:29:32 GMT
Server: Apache/1.3.9 (Unix) mod_perl/1.21
Location: /us/wx/PA/
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="/us/wx/PA/">here</A>.<P>
</BODY></HTML>


Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi guys,

Do you think you could take this off-list now?

73,
Ged.


Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Robert" == Robert Landrum <rl...@capitoladvantage.com> writes:

Robert> That's what the RFC says... But that's not the way that a browser
Robert> handles it.  I don't know why browsers don't support the "standards,"
Robert> but that's not exactly the topic.

Robert> Every browser I've ever tested with, including LWP, lynx and AOL, have
Robert> supported relative Location headers.

No... they've never seen one in their life.  See below.

Robert> If the W3 wants to document it incorrectly or change the unofficial
Robert> standard, then they are wasting their time.

Wait... let's start getting some terminology straight.  Let's stop
talking about "relative" and "absolute" URLs with respect to the
Location: CGI response.  That's just gonna confuse terminology.

If a CGI script sends out a Location: header that doesn't begin with a
protocol (like http: or ftp:), then it's an *internal* redirect.

For an internal redirect, the browser never sees the transaction.  The
web server just does a "goto", picking up the new resource, delivering
the content to the browser AS IF IT WAS THE OLD URL.  The browser
doesn't even know it happened (thus the problem I said earlier about
relative URLs in the delivered document being broken).

If there was a Set-Cookie header on this internal redirect, THE
BROWSER NEVER SEES IT.

If the CGI script instead sends a protocol first in the Location,
(like http://perltraining.stonehenge.com), that's an *external*
redirect, and turns into one of the headers sent to the browser, along
with a Set-Cookie if present.  The *browser* then fetches the new URL
as a separate transaction.

Nearly always, what you want is an *external* redirect.  The relative
URLs in the new document are correct, and cookies get set as needed.

If you are using an *internal* redirect, BE VERY VERY CAREFUL THAT
THIS IS WHAT YOU WANT.  Nearly always... *never*.

Does that help?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

Posted by Michael Peppler <mp...@peppler.org>.
Robert Landrum writes:
 > 
 > Every browser I've ever tested with, including LWP, lynx and AOL, 
 > have supported relative Location headers.

I've made the mistake of using relative (i.e. without the scheme) URLs
in Location headers, and although it worked most of the time there
were situations where it broke (I now forget what that was - it was
some time ago).

Michael
-- 
Michael Peppler - Data Migrations Inc. - mpeppler@peppler.org
http://www.mbay.net/~mpeppler - mpeppler@mbay.net
International Sybase User Group - http://www.isug.com
Sybase on Linux mailing list: ase-linux-list@isug.com

Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)

Posted by Robin Berjon <ro...@knowscape.com>.
At 18:19 08/02/2001 -0500, Robert Landrum wrote:
>Every browser I've ever tested with, including LWP, lynx and AOL, 
>have supported relative Location headers.

Lynx will likely give you a warning on that (though admittedly it'll work).
A good number of Netscape servers will react to it in an interestingly
varied array of ways, ranging from returning a 5xx (not always the same
one) to completely crashing, or going into what looks like an endless loop
consuming lots of cpu and memory.

You probably don't care if you're running modperl, but as is often the case
with many standard vs broken implementation problem, you're usually better
off sticking to the standard.

-- robin b.
Earth is a beta site.