«

Hi,

Let's say a page does an XHR to theSameDomain, and the response is a
redirect to a another resource in another domain. Is that legal ? Will
such an XHR succeed ?

TIA,
--
Jorge.

On Feb 26, 11:37 am, Jorge wrote:
> Let's say a page does an XHR to theSameDomain, and the response
> is a redirect to a another resource in another domain. Is that
> legal ?

Any normal HTTP exchange is 'legal'. (Some may still not be supported
(such as some operations))

> Will such an XHR succeed ?

Succeed is too subjective. If you make an XML HTTP request and the
status of the response is one of the redirection statuses with a new
URL location then that is success in one sense (and the client-side
code can observe the status and the alternative URL and make some
decision about how it is going to act).

I suspect that you mean; will the XML HTTP request system
automatically act on the redirection and return the response from that
alternative source. To which the answer is that mostly they will.
There were Opera versions that did not, but they had to change that as
web developers mostly cannot cope with HTTP and so were declaring
Opera broken when it only did what they asked for instead of what they
expected.

Richard.

On Feb 26, 12:55*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> On Feb 26, 11:37 am, Jorge wrote:
>
> > Let's say a page does an XHR to theSameDomain, and the response
> > is a redirect to a another resource in another domain. Is that
> > legal ?
>
> Any normal HTTP exchange is 'legal'. (Some may still not be supported
> (such as some operations))
>
> > Will such an XHR succeed ?
>
> Succeed is too subjective. If you make an XML HTTP request and the
> status of the response is one of the redirection statuses with a new
> URL location then that is success in one sense (and the client-side
> code can observe the status and the alternative URL and make some
> decision about how it is going to act).
>
> I suspect that you mean; will the XML HTTP request system
> automatically act on the redirection and return the response from that
> alternative source. To which the answer is that mostly they will.
> There were Opera versions that did not, but they had to change that as
> web developers mostly cannot cope with HTTP and so were declaring
> Opera broken when it only did what they asked for instead of what they
> expected.

Ok. Thanks, Richard. One more question would be, isn't that a blatant
violation of the SOP ? What happens if the redirect is to bank.com/
operate/transferNow?amount=10000&destAccount=myAcctNumber ? Would
bank.com cookies be sent along in the 2nd -redirected- request ?
--
Jorge.

On Feb 26, 1:35 pm, Jorge wrote:
> On Feb 26, 12:55 pm, Richard Cornford wrote:
>> On Feb 26, 11:37 am, Jorge wrote:
>
>>> Let's say a page does an XHR to theSameDomain, and the response
>>> is a redirect to a another resource in another domain. Is that
>>> legal ?
>
>> Any normal HTTP exchange is 'legal'. (Some may still not be
>> supported (such as some operations))
>
>> > Will such an XHR succeed ?
>
>> Succeed is too subjective. If you make an XML HTTP request
>> and the status of the response is one of the redirection
>> statuses with a new URL location then that is success in
>> one sense (and the client-side code can observe the status
>> and the alternative URL and make some decision about how
>> it is going to act).
>
>> I suspect that you mean; will the XML HTTP request system
>> automatically act on the redirection and return the response
>> from that alternative source. To which the answer is that
>> mostly they will. There were Opera versions that did not,
>> but they had to change that as web developers mostly cannot
>> cope with HTTP and so were declaring Opera broken when it
>> only did what they asked for instead of what they expected.
>
> Ok. Thanks, Richard. One more question would be, isn't that
> a blatant violation of the SOP ?

I haven't ever tired re-directing across domains. It is asking for
trouble. I would expect an XML HTTP request object to deny access to
any response from a different domain.

> What happens if the redirect is to bank.com/
> operate/transferNow?amount=10000&destAccount=myAcctNumber ? Would
> bank.com cookies be sent along in the 2nd -redirected- request ?

Cookies should follow the rules for cookies. Which cookies go with
which requests depends on their (actual or implied) Path and Domain
parameters.

However, it would be reckless to be sending instructions to be acted
upon (especially in a financial context) in a cookie.

Richard.

On Feb 26, 3:56*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> On Feb 26, 1:35 pm, Jorge wrote:
>
>
>
>
>
> > On Feb 26, 12:55 pm, Richard Cornford *wrote:
> >> On Feb 26, 11:37 am, Jorge wrote:
>
> >>> Let's say a page does an XHR to theSameDomain, and the response
> >>> is a redirect to a another resource in another domain. Is that
> >>> legal ?
>
> >> Any normal HTTP exchange is 'legal'. (Some may still not be
> >> supported (such as some operations))
>
> >> > Will such an XHR succeed ?
>
> >> Succeed is too subjective. If you make an XML HTTP request
> >> and the status of the response is one of the redirection
> >> statuses with a new URL location then that is success in
> >> one sense (and the client-side code can observe the status
> >> and the alternative URL and make some decision about how
> >> it is going to act).
>
> >> I suspect that you mean; will the XML HTTP request system
> >> automatically act on the redirection and return the response
> >> from that alternative source. To which the answer is that
> >> mostly they will. There were Opera versions that did not,
> >> but they had to change that as web developers mostly cannot
> >> cope with HTTP and so were declaring Opera broken when it
> >> only did what they asked for instead of what they expected.
>
> > Ok. Thanks, Richard. One more question would be, isn't that
> > a blatant violation of the SOP ?
>
> I haven't ever tired re-directing across domains. It is asking for
> trouble. I would expect an XML HTTP request object to deny access to
> any response from a different domain.

Denying access to the response might be a good thing, yes, but, by
then it might be too late already. I think that the 2nd request -to
the redirected domain/resource- should -probably- be discarded -never
made- by the XHR object... ¿? Or maybe not, that's why I'm asking.

> > What happens if the redirect is to bank.com/
> > operate/transferNow?amount=10000&destAccount=myAcctNumber ? Would
> > bank.com cookies be sent along in the 2nd -redirected- request ?
>
> Cookies should follow the rules for cookies. Which cookies go with
> which requests depends on their (actual or implied) Path and Domain
> parameters.

But you know that there are circumstances under which existing cookies
are *not* sent.

> However, it would be reckless to be sending instructions to be acted
> upon (especially in a financial context) in a cookie.

I was thinking about session ID cookies.
--
Jorge.

On Feb 26, 3:24 pm, Jorge wrote:
> On Feb 26, 3:56 pm, Richard Cornford wrote:
<snip>
>> I haven't ever tired re-directing across domains. It is
>> asking for trouble. I would expect an XML HTTP request
>> object to deny access to any response from a different
>> domain.
>
> Denying access to the response might be a good thing,
> yes, but, by then it might be too late already. I think
> that the 2nd request -to the redirected domain/resource-
> should -probably- be discarded -never made- by the XHR
> object... ¿? Or maybe not, that's why I'm asking.

Look at what RFC 2616 has to say on the subject. Among other things,
it says that automatic redirecting following a 30X response is only
allowed if the second request uses the GET or HEAD methods, and that
GET and HEAD are both idempotent. So there should (assuming whoever is
responsible for the redirected/redirecting resources understood the
responsibilities of their task) be no significant consequences of
making the request or not making it.

If an XML HTTP request object was going to refuse to automatically
redirect then it should present the status 30X response to the calling
code, and let it work out what to do next.

>>> What happens if the redirect is to bank.com/
>>> operate/transferNow?amount=10000&destAccount=myAcctNumber ?
>>> Would bank.com cookies be sent along in the 2nd -redirected-
>>> request ?
>
>> Cookies should follow the rules for cookies. Which cookies
>> go with which requests depends on their (actual or implied)
>> Path and Domain parameters.
>
> But you know that there are circumstances under which existing
> cookies are *not* sent.

That is what the rules for cookies say is possible. So your point is?

>> However, it would be reckless to be sending instructions to
>> be acted upon (especially in a financial context) in a cookie.
>
> I was thinking about session ID cookies.

If ever there was a type of cookie that should be restricted to a
single domain it is a session ID cookie.

Richard.

On Feb 26, 6:06*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> On Feb 26, 3:24 pm, Jorge wrote:
>
> > On Feb 26, 3:56 pm, Richard Cornford wrote:
> <snip>
> >> I haven't ever tired re-directing across domains. It is
> >> asking for trouble. I would expect an XML HTTP request
> >> object to deny access to any response from a different
> >> domain.
>
> > Denying access to the response might be a good thing,
> > yes, but, by then it might be too late already. I think
> > that the 2nd request -to the redirected domain/resource-
> > should -probably- be discarded -never made- by the XHR
> > object... ¿? Or maybe not, that's why I'm asking.
>
> Look at what RFC 2616 has to say on the subject. Among other things,
> it says that automatic redirecting following a 30X response is only
> allowed if the second request uses the GET or HEAD methods, and that
> GET and HEAD are both idempotent. So there should (assuming whoever is
> responsible for the redirected/redirecting resources understood the
> responsibilities of their task) be no significant consequences of
> making the request or not making it.
>
> If an XML HTTP request object was going to refuse to automatically
> redirect then it should present the status 30X response to the calling
> code, and let it work out what to do next.

ISTM -looking at it into w3.org- that it will throw either a security
err or a network err:

<quote>
If the response is an HTTP redirect:
If the redirect does not violate security (it is same origin for
instance), infinite loop precautions, and the scheme is supported,
transparently follow the redirect while observing the same-origin
request event rules.

HTTP places requirements on the user agent regarding the preservation
of the request method and request entity body during redirects, and
also requires end users to be notified of certain kinds of automatic
redirections.

Otherwise, this is a network error.
</quote>

> >>> What happens if the redirect is to bank.com/
> >>> operate/transferNow?amount=10000&destAccount=myAcctNumber ?
> >>> Would bank.com cookies be sent along in the 2nd -redirected-
> >>> request ?
>
> >> Cookies should follow the rules for cookies. Which cookies
> >> go with which requests depends on their (actual or implied)
> >> Path and Domain parameters.
>
> > But you know that there are circumstances under which existing
> > cookies are *not* sent.
>
> That is what the rules for cookies say is possible. So your point is?

That it might have been that this were another of these circumstances.

> >> However, it would be reckless to be sending instructions to
> >> be acted upon (especially in a financial context) in a cookie.
>
> > I was thinking about session ID cookies.
>
> If ever there was a type of cookie that should be restricted to a
> single domain it is a session ID cookie.

Exactly. Therefore my worry.

Thanks,
--
Jorge.

On Feb 26, 5:31 pm, Stefan Weiss wrote:
> On 26/02/10 18:06, Richard Cornford wrote:
<snip>
>> If an XML HTTP request object was going to refuse to
>> automatically redirect then it should present the status
>> 30X response to the calling code, and let it work out
>> what to do next.
>
> That is exactly what Firefox does. Opera also won't follow
> the redirect automatically, but its xhr.status value is 0
> for some reason.
>
> I didn't try any other browsers, but I would be very surprised
> if any of them (the more recent ones, at least) could be tricked
> into sending an XHR which violates the browser's security policies
> by something as simple as an HTTP redirect.

Why not? For a very long time it has been possible to 'trick' a
browser into making a request to another domain by setting the - src -
of a - new Image(); -. Making the request or not is not that important
so long as access to the result is denied.

Richard.

On Feb 26, 12:40*pm, Richard Cornford wrote:
> On Feb 26, 5:31 pm, Stefan Weiss wrote:
>> I didn't try any other browsers, but I would be very surprised
>> if any of them (the more recent ones, at least) could be tricked
>> into sending an XHR which violates the browser's security policies
>> by something as simple as an HTTP redirect.
>
> Why not? For a very long time it has been possible to 'trick' a
> browser into making a request to another domain by setting the - src -
> of a - new Image(); -. Making the request or not is not that important
> so long as access to the result is denied.

.... and if the request is actually idempotent. I know GET and HEAD
requests are supposed to be, but we all remember the havoc caused with
many sites when some prefetching was released (was it Google Web
Accelerator?)

-- Scott

On Feb 26, 5:26 pm, Jorge wrote:
> On Feb 26, 6:06 pm, Richard Cornford wrote:
<snip>
>> If an XML HTTP request object was going to refuse to
>> automatically redirect then it should present the status
>> 30X response to the calling code, and let it work out what
>> to do next.
>
> ISTM -looking at it into w3.org- that it will throw either
> a security err or a network err:

As I said, attempting a cross-domain redirect is asking for trouble.

> <quote>
<snip>

If you quote something you really should say what it is you are
quoting. Citing "w3.org" doesn't quite achieve that.

>>>> Cookies should follow the rules for cookies. Which cookies
>>>> go with which requests depends on their (actual or implied)
>>>> Path and Domain parameters.
>
>>> But you know that there are circumstances under which existing
>>> cookies are *not* sent.
>
>> That is what the rules for cookies say is possible. So your
>> point is?
>
> That it might have been that this were another of these
> circumstances.

That what might be "another of these circumstances"?

>>>> However, it would be reckless to be sending instructions to
>>>> be acted upon (especially in a financial context) in a cookie.
>
>>> I was thinking about session ID cookies.
>
>> If ever there was a type of cookie that should be restricted
>> to a single domain it is a session ID cookie.
>
> Exactly. Therefore my worry.

What worry? If the cookie is set with no Domain the result is that it
is restricted to the domain that sets the cookie, and it will not be
sent with any requests to other domains. If a Domain is specified then
the UA should not send that cookie to any other domain.

Richard.