XHR redirects

Discussion in 'Javascript' started by Jorge, Feb 26, 2010.

  1. Jorge

    Jorge Guest

    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.
     
    Jorge, Feb 26, 2010
    #1
    1. Advertising

  2. 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.
     
    Richard Cornford, Feb 26, 2010
    #2
    1. Advertising

  3. Jorge

    Jorge Guest

    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 ? 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.
     
    Jorge, Feb 26, 2010
    #3
  4. 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.
     
    Richard Cornford, Feb 26, 2010
    #4
  5. Jorge

    Jorge Guest

    On Feb 26, 3:56 pm, Richard Cornford <>
    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.
     
    Jorge, Feb 26, 2010
    #5
  6. 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.
     
    Richard Cornford, Feb 26, 2010
    #6
  7. Jorge

    Jorge Guest

    On Feb 26, 6:06 pm, Richard Cornford <>
    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.
     
    Jorge, Feb 26, 2010
    #7
  8. 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.
     
    Richard Cornford, Feb 26, 2010
    #8
  9. Jorge

    Scott Sauyet Guest

    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
     
    Scott Sauyet, Feb 26, 2010
    #9
  10. 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.
     
    Richard Cornford, Feb 26, 2010
    #10
  11. On Feb 26, 5:58 pm, Scott Sauyet wrote:
    > 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.


    Alright, what 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?)


    I have absolutely no idea what you are talking about.

    Richard.
     
    Richard Cornford, Feb 26, 2010
    #11
  12. Jorge

    Jorge Guest

    On Feb 26, 6:59 pm, Richard Cornford <>
    wrote:
    > On Feb 26, 5:26 pm, Jorge wrote:
    > > On Feb 26, 6:06 pm, Richard Cornford wrote:

    >
    > >>>> 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.


    This worry:

    1.- You login to your bank at bank.com.
    2.- Your browser has a session cookie for bank.com
    3.- You open a new window.
    4.- You enter someOtherSite.com.
    5.- the page from someOtherSite.com does an XHR to someOtherSite.com
    6.- the response to that XHR is a redirect to bank.com
    7.- as a consequence of step#6, another request is made to bank.com
    from the someOtherSite.com page
    8.- Does the request at step 7 carry the cookie of step 2 (that's my
    worry) ?

    --
    Jorge.
     
    Jorge, Feb 26, 2010
    #12
  13. Jorge

    Jorge Guest

    On Feb 26, 6:59 pm, Richard Cornford <>
    wrote:
    > 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.


    You said as well:

    <quote>
    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.
    </quote>

    --
    Jorge.
     
    Jorge, Feb 26, 2010
    #13
  14. Jorge

    Jorge Guest

    On Feb 26, 6:59 pm, Richard Cornford <>
    wrote:
    > On Feb 26, 5:26 pm, Jorge wrote:
    > > On Feb 26, 6:06 pm, Richard Cornford wrote:

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

    >
    ><HERE> But you know that there are circumstances under which existing
    > >>> cookies are *not* sent.</HERE>

    >
    > >> 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"?


    See the <HERE> element, ↑↑↑ above ↑↑↑
    --
    Jorge.
     
    Jorge, Feb 26, 2010
    #14
  15. Jorge

    Scott Sauyet Guest

    On Feb 26, 1:15 pm, Richard Cornford wrote:
    > On Feb 26, 5:58 pm, Scott Sauyet wrote:
    >
    > > 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.

    >
    > Alright, what if the request is actually idempotent?


    I meant to qualify your statement further. I mean that making the
    request or not is not that important so long as both (1) access to the
    result is denied and (2) the request is actually idempotent. A GET
    request is supposed to be idempotent, but if it's not, then having
    that request made on redirect could cause problems.

    >> 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?)

    >
    > I have absolutely no idea what you are talking about.


    At some point a few years back a browser plug-in was released; I
    think it might have been Google Web Accelerator. [1] This tool was
    supposed to speed up browsing by pre-fetching and caching links it
    thought you might visit off the current page. It makes perfect sense,
    except that a number of web applications out there had non-idempotent
    GET request, especially hyperlinked "delete row" actions. People
    started unintentionally altering all sorts of data using this tool.
    Granted, it was the fault of people not smart enough to develop
    properly with HTTP, but it was pretty easy to blame Google. The plug-
    in is long gone now.

    -- Scott
    ____________________
    [1] http://en.wikipedia.org/wiki/Google_Web_Accelerator
     
    Scott Sauyet, Feb 26, 2010
    #15
  16. Jorge

    Ivan S Guest

    On Feb 27, 2:31 am, Stefan Weiss <> wrote:
    > 5) TAN/TAC, SMS, USB dongle, etc: most banks require some external code
    > to finalize a transaction. Some send their customers a list of numbers
    > with pre-generated codes, some use SMS to send that code, some require a
    > USB device. I've even heard that some banks require you to boot from a
    > CDROM they provide. All of these can effectively foil CSRF attacks.



    If I may add, hardware token generators and recently mobile software
    token generators which are becoming very popular (at least in Europe).

    Token number combins with (short) static password, as extra protection
    in cases of token generator theft or something like that.


    So ... there is always more than one way of authorization for banking
    transations.
     
    Ivan S, Feb 27, 2010
    #16
  17. On Feb 26, 3:37 am, Jorge <> wrote:
    > 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 ?


    http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method

    ---------
    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.

    Note: 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.
    ---------

    Peter
     
    Peter Michaux, Feb 27, 2010
    #17
  18. Peter Michaux wrote:

    > 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 ? Will
    >> such an XHR succeed ?

    >
    > http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method
    > [...]


    | Publication as a Working Draft does not imply endorsement by the W3C
    | Membership. This is a draft document and may be updated, replaced or
    | obsoleted by other documents at any time. It is inappropriate to cite
    | this document as other than work in progress.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
     
    Thomas 'PointedEars' Lahn, Feb 28, 2010
    #18
  19. On Feb 26, 6:49 pm, Jorge wrote:
    > On Feb 26, 6:59 pm, Richard Cornford wrote:
    >> 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.

    >
    > You said as well:
    >
    > <quote>
    > 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.
    > </quote>


    Redirecting will mostly not be attempted cross-domain.

    Richard.
     
    Richard Cornford, Mar 1, 2010
    #19
  20. On Feb 26, 6:53 pm, Jorge wrote:
    > On Feb 26, 6:59 pm, Richard Cornford wrote:
    >> On Feb 26, 5:26 pm, Jorge wrote:
    >>> On Feb 26, 6:06 pm, Richard Cornford wrote:

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

    >
    >><HERE> But you know that there are circumstances under which
    >>>>> existing
    >>>>> cookies are *not* sent.</HERE>

    >
    >>>> 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"?

    >
    > See the <HERE> element, ??? above ???


    When you are not being understood, repeating yourself slightly louder
    is a waste of everyone's time.

    Richard.
     
    Richard Cornford, Mar 1, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Erich Lin

    multiple xhr requests

    Erich Lin, Jul 6, 2006, in forum: Ruby
    Replies:
    3
    Views:
    196
    Erich Lin
    Jul 7, 2006
  2. Adam Ratcliffe

    Set document loaded by XHR into Frame

    Adam Ratcliffe, Apr 16, 2005, in forum: Javascript
    Replies:
    0
    Views:
    104
    Adam Ratcliffe
    Apr 16, 2005
  3. Sri
    Replies:
    0
    Views:
    139
  4. NeoAlchemy
    Replies:
    3
    Views:
    115
    NeoAlchemy
    Feb 17, 2007
  5. -Lost
    Replies:
    4
    Views:
    171
    Cah Sableng
    May 4, 2007
Loading...

Share This Page