SoupCache: do not store Set-Cookie - or do not revive it on 304
Submitted by kap..@..ix.org
Assigned to libsoup-maint@gnome.bugs
Link to original bug (#746796)
Description
Hi,
i'm having an issue in webkit2gtk (2.6 to 2.8) and soup (2.48.0 to 2.50.0) on an up-to-date debian/jessie install:
- a web page makes xhr requests, each of which receives different Set-Cookie and ETag response headers.
- later on, the page is loaded on another url, and its document.cookie is set by javascript (that is probably not something that is important, but that is what is done on the failing setup); then more xhr requests are done, each of which does NOT receive Set-Cookie headers.
- one of the xhr requests triggers a 304 match, libsoup handles it, and when that request happen before the others are sent, the old Cookie field from first step is sent to the server.
Upon suggestion of Carlos, i investigated libsoup and found that not storing Set-Cookie field in the cache solved my issue.
I cannot reproduce the problem in a simple setup where i do exactly what i mention here. Somehow this happens only when some delays are introduced in the way the webkitgtk client do its requests - in the complex setup i'm seeing the bug, the requests are caught by a web-extension send-request listener, like there: https://github.com/kapouer/node-webkitgtk/blob/master/src/webextension.cc#L37
thank you for your attention.
Version: 2.50.x