Re: Redirection Location MUST be absolute (was Re: Send a cookie,AND a redirect ?)
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 302 Found Found The document has moved here.
Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)
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 ?)
> "Robert" == Robert Landrum <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ?)
We only use absolute URLs /images/some.gif. When dealing with apache, it's often neccesary to see the previous requests environment (error pages, etc.) so that you can show that information to the user and email it to the webmaster. That's only possible with an internal redirect. As in ErrorDocument 503 /error.pl Using a full path there causes you to lose all of that valuable information that was stored in the Environment. ErrorDocument 503 http://www.somehost.com/error.pl I almost always use external redirects, except when I don't want the page I'm redirecting to bookmarked. But I definitly understand why you say *NEVER*. Rob > > "Robert" == Robert Landrum <[EMAIL PROTECTED]> writes: > >Robert> By using relative *URLs* such as /some/location, you avoid changing >Robert> the location field in the browser window, which is often desired. If >Robert> you use an absolute *URL*, the location field changes to the absolute >Robert> URL. > >Actually, I'll disagree with that. NEVER use internal redirects >(which you call "relative URLs" but that's another story) unless you >are fully understanding about WHY *I* say *NEVER*, in my strongest >language. > >As a hint... are you willing to be responsible for how all the >relative URLs in the resulting document are treated, including all >documents called from there? > >The problem is that the browser still thinks it got >"/foo/bar/fred.html", so if an internal redirect was performed to >"/abc/def/ghi.html" and it had a relative link to "../xyz.html", the >browser will fetch "/foo/xyz.html", not to the correct >"/abc/xyz.html", since the browser had no visibility to the /abc part >of that equation. > >NEVER use internal redirects. > >At least not until you understand why I say "NEVER". > >-- >Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 ><[EMAIL PROTECTED]> 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! 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 ?)
___cliff rayman___ wrote: > you are supposed to be able to use: > make that: http://host.mydomain.net/foo/bar/fred.html"> > > > which changes the base of the document. if u really wanted to use internal > redirects, you would have to insure that all documents contained this tag, > or filter the page and include it yourself. > > of course this is just a spec, determining which browsers properly use > it, is beyond me. > > -- > ___cliff [EMAIL PROTECTED]http://www.genwax.com/ > > "Randal L. Schwartz" wrote: > > > > "Robert" == Robert Landrum <[EMAIL PROTECTED]> writes: > > > > Robert> By using relative *URLs* such as /some/location, you avoid changing > > Robert> the location field in the browser window, which is often desired. If > > Robert> you use an absolute *URL*, the location field changes to the absolute > > Robert> URL. > > > > Actually, I'll disagree with that. NEVER use internal redirects > > (which you call "relative URLs" but that's another story) unless you > > are fully understanding about WHY *I* say *NEVER*, in my strongest > > language. > > > > As a hint... are you willing to be responsible for how all the > > relative URLs in the resulting document are treated, including all > > documents called from there? > > > > The problem is that the browser still thinks it got > > "/foo/bar/fred.html", so if an internal redirect was performed to > > "/abc/def/ghi.html" and it had a relative link to "../xyz.html", the > > browser will fetch "/foo/xyz.html", not to the correct > > "/abc/xyz.html", since the browser had no visibility to the /abc part > > of that equation. > > > > NEVER use internal redirects. > > > > At least not until you understand why I say "NEVER". -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)
you are supposed to be able to use: which changes the base of the document. if u really wanted to use internal redirects, you would have to insure that all documents contained this tag, or filter the page and include it yourself. of course this is just a spec, determining which browsers properly use it, is beyond me. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ "Randal L. Schwartz" wrote: > > "Robert" == Robert Landrum <[EMAIL PROTECTED]> writes: > > Robert> By using relative *URLs* such as /some/location, you avoid changing > Robert> the location field in the browser window, which is often desired. If > Robert> you use an absolute *URL*, the location field changes to the absolute > Robert> URL. > > Actually, I'll disagree with that. NEVER use internal redirects > (which you call "relative URLs" but that's another story) unless you > are fully understanding about WHY *I* say *NEVER*, in my strongest > language. > > As a hint... are you willing to be responsible for how all the > relative URLs in the resulting document are treated, including all > documents called from there? > > The problem is that the browser still thinks it got > "/foo/bar/fred.html", so if an internal redirect was performed to > "/abc/def/ghi.html" and it had a relative link to "../xyz.html", the > browser will fetch "/foo/xyz.html", not to the correct > "/abc/xyz.html", since the browser had no visibility to the /abc part > of that equation. > > NEVER use internal redirects. > > At least not until you understand why I say "NEVER".
Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)
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.
Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)
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. - [EMAIL PROTECTED] http://www.mbay.net/~mpeppler - [EMAIL PROTECTED] International Sybase User Group - http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
Re: Redirection Location MUST be absolute (was Re: Send a cookie, AND a redirect ?)
> "Robert" == Robert Landrum <[EMAIL PROTECTED]> writes: Robert> By using relative *URLs* such as /some/location, you avoid changing Robert> the location field in the browser window, which is often desired. If Robert> you use an absolute *URL*, the location field changes to the absolute Robert> URL. Actually, I'll disagree with that. NEVER use internal redirects (which you call "relative URLs" but that's another story) unless you are fully understanding about WHY *I* say *NEVER*, in my strongest language. As a hint... are you willing to be responsible for how all the relative URLs in the resulting document are treated, including all documents called from there? The problem is that the browser still thinks it got "/foo/bar/fred.html", so if an internal redirect was performed to "/abc/def/ghi.html" and it had a relative link to "../xyz.html", the browser will fetch "/foo/xyz.html", not to the correct "/abc/xyz.html", since the browser had no visibility to the /abc part of that equation. NEVER use internal redirects. At least not until you understand why I say "NEVER". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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 ?)
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 ?)
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
Re: Redirection Location MUST be absolute (was Re: Send a cookie,AND a redirect ?)
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 But so is http://www.somehost.com/some/location Both are valid URIs and both absolute. One is more qualified than the other. 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. 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"; Robert Landrum >On Thu, 8 Feb 2001, Robert Landrum wrote: > >> The problem is that Apache does not put the "Set-Cookie" before the >> "Location" when generating headers. To fix this, you need to build >> the header yourself. I've found that this works with Netscape and >> IE, but with IE, the place where you redirect to does not have access >> to the cookie that you just set. All subsequent pages are able to >> read the cookie... It's a bug in IE. >> >> >> my $cookie = Apache::Cookie->new($r, >> -name => "MYCOOKIE", >> -value => "VALUE", >> -path => "/some/cookie/path" >> ); >> >> my %headers = ( >> "Location" => "/some/redirect/location", > >I'd like to mention that the Location header MUST be absolute, NEVER >relative. Absolute means that it must include the scheme! > >http://www.w3.org/Protocols/rfc2068/rfc2068 > >14.30 Location > > The Location response-header field is used to redirect the recipient > to a location other than the Request-URI for completion of the > request or identification of a new resource. For 201 (Created) > responses, the Location is that of the new resource which was created > by the request. For 3xx responses, the location SHOULD indicate the > server's preferred URL for automatic redirection to the resource. The > field value consists of a single absolute URL. > > Location = "Location" ":" absoluteURI > > An example is > > Location: http://www.w3.org/pub/WWW/People.html > > >-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