Intended that session is saved _after_ the response is written?

[igrayson]

Hi,

We have a simple client that sends two requests to a server using express-session:

1. /login creates a session; store.set writes a postgres sessions row and triggers the session store callback after committed.
2. /getSomeData requires a session to exist. The client calls this immediately after receiving the response to /login.

Our problem: the server receives /getSomeData before the postgres finishes writing to sessions.

With some breakpoints and tcpdump, I discovered that express-session intercepts request.end(), to call store.set before request.end is called. However, tcpdump demonstrates the response may already be completed -- written to the wire -- by this point (e.g., request.write() has already been called).

Question: is it intended that the session is saved after the response is written to the wire?

If so, is there a concern that this allows a race condition where follow-up requests may present a cookie for a session that has not yet been saved?

[dougwilson]

Hi @igrayson . Yes, this is intentional, mainly because Node.js does not provide a good mechanism in order to pause at the header write, as the header write API is sync only, and almost all stores will make a network call, which cannot be done sync. Instead of starting the async call on header write and hoping it completes, instead this module will simply always write at the end, so it's consistent.

If you want to write before sending the response, you'll want to call req.session.save, and then put your response writing logic within the callback function of req.session.save.

[gireeshpunathil]

just illustrating @dougwilson 's proposal in code form to make it explicit

app.get('/foo', function (req, res, next) {
  // other logic
  req.session.save(function(err) {
    // guaranteed that session is saved by this time
    res.send(response)
  })
})

@igrayson - does this approach help you?

[jkantr]

@dougwilson sorry to ping here... but this is sort of one of the major non-obvious, not-really-documented issues with express-session. At one point I don't believe that most browsers were so aggressive in following redirects before a response had been completely receieved - but these days everything is about "fast" so this slowly became a problem. Something like 6 or 7 open issues right now are ultimately just people confused about this. And spending a lot of time in ##javascript and #Node.js on freenode, I can tell you it's a regular thing.

In... theory - could we warn the user of this during development and how to fix it? In the res.end() proxy, couldn't we check isModified(req) && shouldSave(req.sess) && /3\d{2}/.test(res.statusCode) to see the case of "Session was modified, session should be saved, session has not been saved, and a redirect was set to the response". This would always lead to the behavior of the session not containing the saved data on the subsequent GET request (or at least a race condition which generally will have the unexpected behavior). Then the warning message could suggest calling res.redirect in the req.session.save() callback.. or point to a URL / section in the doc that explains it? Just a thought.

[dougwilson]

Yes, there are a lot of possible things that can be done. The question above was answered and then no follow up from OP, so I'm closing this issue as answered.

But for your points above, you are welcome and encouraged to make a pull request with a solution you think will help if you would like to see something appear in a timely manner. Otherwise I can certainly put together a change, but cannot promise when it would appear.