Likes: 0
..oO(Marcin Dobrucki)
>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.
A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.
Micha
..oO(Marcin Dobrucki)
>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.
A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.
Micha
..oO(Marcin Dobrucki)
>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.
A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.
Micha
..oO(Marcin Dobrucki)
>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.
A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.
Micha
..oO(Marcin Dobrucki)
>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.
A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.
Micha
Michael Fesser wrote:
> .oO(Marcin Dobrucki)
>
>
>>Michael Fesser wrote:
>>
>>>First you should fix the error in the redirect. The Location header
>>>requires an absolute URL.
>>
>> True. But it seems to work with relative URLs as well.
>
>
> A bug is a bug and should be fixed, especially if you're searching for
> the reason of another bug, which could be caused by the first.
>
> Micha
Yep, bugs need to be fixed. But how many times do people have to tell
you that PHP is working exactly according to the RFC's?
Additionally, it's not just PHP. It's every browser on the market.
Session ID's are kept in cookies. And even the browsers agree that
example.com is not the same as www.example.com - and will not send a
cookie generated by one host to the other.
If you don't like it, fine. Put in your own RFC and get the entire
internet to change. But don't keep complaining about it being a bug
just because it doesn't work like *you* would like it to. It's been
like that for almost 40 years, since it was arpanet. I know for sure it
was like that in the early 70's when I was on arpanet. And that's the
way it's designed to work.
As much as I hate to tell you, the internet does NOT revolve around Micha.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
..oO(Jerry Stuckle)
>If you don't like it, fine. Put in your own RFC and get the entire
>internet to change. But don't keep complaining about it being a bug
>just because it doesn't work like *you* would like it to.
RFC 2616, section 14.30 "Location":
| The field value consists of a single absolute URI.
Micha
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>
>>If you don't like it, fine. Put in your own RFC and get the entire
>>internet to change. But don't keep complaining about it being a bug
>>just because it doesn't work like *you* would like it to.
>
>
> RFC 2616, section 14.30 "Location":
>
> | The field value consists of a single absolute URI.
>
> Micha
And there isn't a browser currently made which doesn't understand the
relative URI here.
Agreed the RFC indicates we need to use an absolute URI. And he should
be using one.
But that isn't his problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
..oO(Jerry Stuckle)
>And there isn't a browser currently made which doesn't understand the
>relative URI here.
Browsers are not the only user agents. It's impossible to test them all,
so you can't be sure that all of them will handle a relative redirect
with a query string correctly. Some of them even show a warning (Lynx
for example).
>Agreed the RFC indicates we need to use an absolute URI. And he should
>be using one.
>
>But that isn't his problem.
It could be, depending on the used combination of server and browser.
Unlikely, but not impossible.
Micha
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>
>>And there isn't a browser currently made which doesn't understand the
>>relative URI here.
>
>
> Browsers are not the only user agents. It's impossible to test them all,
> so you can't be sure that all of them will handle a relative redirect
> with a query string correctly. Some of them even show a warning (Lynx
> for example).
>
True, some are better than others. But can you name one http agent
which doesn't understand relative URI's?
>
>>Agreed the RFC indicates we need to use an absolute URI. And he should
>>be using one.
>>
>>But that isn't his problem.
>
>
> It could be, depending on the used combination of server and browser.
> Unlikely, but not impossible.
>
> Micha
Nope. Guaranteed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Sat, 11 Nov 2006 22:31:23 -0500, Jerry Stuckle <jstucklex@attglobal.net>
wrote:
>Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>>And there isn't a browser currently made which doesn't understand the
>>>relative URI here.
>>
>> Browsers are not the only user agents. It's impossible to test them all,
>> so you can't be sure that all of them will handle a relative redirect
>> with a query string correctly. Some of them even show a warning (Lynx
>> for example).
>
>True, some are better than others. But can you name one http agent
>which doesn't understand relative URI's?
[for context: in Location response headers]
If you search Google, you will find several references where HTTP client
libraries in various languages fail when they encounter invalid Location
headers, and some other cases where there are issues with the code added to
work around the invalid Location headers - and so it goes on.
For example, cURL has the following comments:
if(2 != sscanf(newurl, "%15[^?&/:]://%c", prot, &letter)) {
/***
*DANG* this is an RFC 2068 violation. The URL is supposed
to be absolute and this doesn't seem to be that!
***
Instead, we have to TRY to append this new path to the old URL
to the right of the host part. Oh crap, this is doomed to cause
problems in the future...
*/
Followed by 93 lines of trying to sort the mess out.
PHP 4.3.0 apparently core dumped in some situations with relative Location
headers (bug#22283). There was also bug #21267, in CVS the comment on the
changed file was "opening URLs that result in redirection to a relative path
was failing".
The minefield can be avoided by following the spec, or you can hope that all
HTTP client library developers have heard of this issue and have added bug-free
code and that their expectation of what to do in this unspecified case is
consistent with other implementations.
Back in the real world, here's an example, let's call it redirect.php:
<?php
if (isset($_GET['value']))
{
print $_GET['value'];
}
else
{
header('Location: ?value=test');
}
?>
Let's say that's on http://example.com/redirect.php
Access it with Firefox 2.0, IE 7 and Opera 9.02 and you get redirected to:
http://example.com/redirect.php?value=test
Access it with cURL 7.14.0, Lynx 2.8.5 and it takes you to:
http://example.com/?value=test
Access it using PHP 5.2.0's HTTP fopen wrapper and it takes you to:
http://example.com//?value=test
(complete with weird double slash).
I wasn't trying very hard to find a case that would produce inconsistent
results, and I found one straight off. That's enough of an indication of the
can of worms that is opened by not following the standards to continue to
always insist that you always write absolute Location headers.
--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
On Thu, 09 Nov 2006 23:15:25 -0500, Jerry Stuckle <jstucklex@attglobal.net>
wrote:
>> A bug is a bug and should be fixed, especially if you're searching for
>> the reason of another bug, which could be caused by the first.
>
>Yep, bugs need to be fixed. But how many times do people have to tell
>you that PHP is working exactly according to the RFC's?
>
>Additionally, it's not just PHP. It's every browser on the market.
>Session ID's are kept in cookies. And even the browsers agree that
>example.com is not the same as www.example.com - and will not send a
>cookie generated by one host to the other.
Er, you seem to have crossed threads here? The "session cookies must magically
cross subdomains according to my own arbitrary criteria" guy was on another
thread.
--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
..oO(Andy Hassall)
> I wasn't trying very hard to find a case that would produce inconsistent
>results, and I found one straight off. That's enough of an indication of the
>can of worms that is opened by not following the standards to continue to
>always insist that you always write absolute Location headers.
I also read multiple times about users having problems with relative
Location headers, especially when there was a query string appended.
This is just one of them (German): <news:ctab04$vns$1@online.de>.
In short: User has a problem with
header("Location: /index.php?pid=5");
His script didn't receive the parameter (like the OP's script). After
fixing it and using an absolute URI it worked as expected. Too bad he
didn't mention the used server and browser.
But he was not the only one encountering this problem.
Micha
Andy Hassall wrote:
> On Sat, 11 Nov 2006 22:31:23 -0500, Jerry Stuckle <jstucklex@attglobal.net>
> wrote:
>
>
>>Michael Fesser wrote:
>>
>>>.oO(Jerry Stuckle)
>>>
>>>
>>>>And there isn't a browser currently made which doesn't understand the
>>>>relative URI here.
>>>
>>>Browsers are not the only user agents. It's impossible to test them all,
>>>so you can't be sure that all of them will handle a relative redirect
>>>with a query string correctly. Some of them even show a warning (Lynx
>>>for example).
>>
>>True, some are better than others. But can you name one http agent
>>which doesn't understand relative URI's?
>
> [for context: in Location response headers]
>
> If you search Google, you will find several references where HTTP client
> libraries in various languages fail when they encounter invalid Location
> headers, and some other cases where there are issues with the code added to
> work around the invalid Location headers - and so it goes on.
>
That isn't what I asked, Andy. And how many of those libraries actually
apply to this problem.
<snip>
>
> Back in the real world, here's an example, let's call it redirect.php:
>
> <?php
> if (isset($_GET['value']))
> {
> print $_GET['value'];
> }
> else
> {
> header('Location: ?value=test');
> }
> ?>
>
> Let's say that's on http://example.com/redirect.php
>
> Access it with Firefox 2.0, IE 7 and Opera 9.02 and you get redirected to:
> http://example.com/redirect.php?value=test
>
> Access it with cURL 7.14.0, Lynx 2.8.5 and it takes you to:
> http://example.com/?value=test
>
> Access it using PHP 5.2.0's HTTP fopen wrapper and it takes you to:
> http://example.com//?value=test
> (complete with weird double slash).
>
> I wasn't trying very hard to find a case that would produce inconsistent
> results, and I found one straight off. That's enough of an indication of the
> can of worms that is opened by not following the standards to continue to
> always insist that you always write absolute Location headers.
>
Again, how does that apply to this problem?
I'm not saying you shouldn't use them. I'm saying that's not the
original poster's problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Andy Hassall wrote:
> On Thu, 09 Nov 2006 23:15:25 -0500, Jerry Stuckle <jstucklex@attglobal.net>
> wrote:
>
>
>>>A bug is a bug and should be fixed, especially if you're searching for
>>>the reason of another bug, which could be caused by the first.
>>
>>Yep, bugs need to be fixed. But how many times do people have to tell
>>you that PHP is working exactly according to the RFC's?
>>
>>Additionally, it's not just PHP. It's every browser on the market.
>>Session ID's are kept in cookies. And even the browsers agree that
>>example.com is not the same as www.example.com - and will not send a
>>cookie generated by one host to the other.
>
>
> Er, you seem to have crossed threads here? The "session cookies must magically
> cross subdomains according to my own arbitrary criteria" guy was on another
> thread.
>
Yep, sorry. It got posted to the wrong thread. Too many windows open! :-)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Quote