New issue
Advanced search Search tips

Issue 620768 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Mar 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

session cookie not updated for long polling request

Reported by ashwiniv...@gmail.com, Jun 16 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36

Steps to reproduce the problem:
1. client js runs the following function on doucment.ready
function startAlarmLongPoll() {
    $.ajax({
        url:"/alarm",
        method:"GET",
    }).done(function(data, textStatus, jqXHR){
        startAlarmLongPoll();
        alert(data);
    }).fail(function(jqXHR, textStatus, errorThrown){
        if (textStatus == "timeout" || jqXHR.status == 408){
            startAlarmLongPoll();
        }
    })
}
2. The server uses cookies to store session that includes a webtoken with expiry time. Some requests from the client js file renew the token which is saved to session in response to the request.
3. The long poll function above never sees the 408 from the server, the browser automatically resends the request, BUT with the old session with non renewed token
4. The server times out because of the session containing expired token when the long poll request is resent by the browser 

What is the expected behavior?
The browser updates the cookie it holds on every response. This updated cookie is sent for subsequent requests.The automatic browser re-sends of the GET \alarm request should send this updated cookie, not the original old cookie

What went wrong?
Server times out because of the unrenewed token

Did this work before? N/A 

Chrome version: 51.0.2704.84  Channel: stable
OS Version: OS X 10.11.5
Flash Version: Shockwave Flash 21.0 r0

Works in Safari
 
Components: UI>Browser>CookiesTree
Components: -UI>Browser>CookiesTree Internals>Network>Cookies
Labels: Needs-Feedback
Thank you for your report.

Is this request cross-origin, with the target origin attempting to set cookies for its own domain? If so, does using the withCredentials attribute (https://www.w3.org/TR/XMLHttpRequest/#the-withcredentials-attribute) help?

Is there a standalone test page that reproduces this issue?

This is a network stack issue, not a UI issue, I think.
No, this is not a cross-origin request. I was testing it on my local
machine though localhost. I dont have a test page to reproduce the issue,
My application uses golang, the server sets the Set-Cookie header in the
response. The subsequent requests from the browser use this updated cookie,
but pending requests that get a 408 (timeout) and that the browser
automatically resends the request go back to the server with the old
cookie.
Project Member

Comment 4 by sheriffbot@chromium.org, Jun 29 2016

Labels: -Needs-Feedback Needs-Review
Owner: ellyjo...@chromium.org
Thank you for providing more feedback. Adding requester "ellyjones@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by cda...@chromium.org, Mar 13 2017

Labels: -Needs-Review
Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919
Project Member

Comment 6 by sheriffbot@chromium.org, Mar 15 2018

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment