From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id BDF8A77EF7 for ; Fri, 1 Jan 2016 10:16:45 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-06v.sys.comcast.net with comcast id 0iH61s00329Cfhx01iHGCp; Fri, 01 Jan 2016 18:17:16 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-03v.sys.comcast.net with comcast id 0iHF1s00X2MDcd701iHFfj; Fri, 01 Jan 2016 18:17:16 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.0+ Date: Fri, 01 Jan 2016 13:17:15 -0500 Message-ID: <20160001131715.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1451672236; bh=rMgzNlVTANx+WZNR15kgsy+pV7OqKDXJ+bGCT5sy5zQ=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=FFu+zbktdB54kKcmeIBLzRGXvfoZYTMQJ1W5q3QUb0xAyF6MlRxKS4FJHbS5RrjxV 96ilwZKyen3lIPuO8P2NSsfkdlS4loEchh5LJNMao7kFLQeErVFatf6bc4OUiu3fY2 EhwQm/j7p7NmnM6ci2HzcaFQc4sAQGgz21Zqbba+pHAV4HW+YxXrxAwKwXxYFsd74d Lwoeatga8Z1W8Ht0Yav4osUSIxwHeWNIDAmUBSNdWKPTjVD+Dlv97gt45bTDb8WCAf 9vm+80a6SwKghEY3e5JJXGDEjhGW3NQVWGlGtvpfj+Ul4xu+8fiy4iXFAfiZwcJs/r CyDMVAot6Cyvg== Subject: [Edbrowse-dev] xhr cookies X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 18:16:46 -0000 Well Kevin pointed out to me something I hadn't thought about at all. His template code includes a piece to update document.cookie, in the current window, as per the cookies that come in through an xhr request. So let's follow it through. xhr does an http fetch. Cookies come back from the website. Cookies are updated in cookie space and in the jar by curl. All good. We return from the http request and javascript sees the http headers. It uses those to adjust document.cookie, the string of current cookies, which doesn't yet have the new cookies in it. Again all good, as long as the xhr url is the same as the current url. Otherwise you're adding foreign cookies to document.cookie, that don't belong there. I thought about replicating all the logic in cookies.c to see if the cookies really belong - compare the xhr url with window.location.lhref. That kind of wheel reinvention really irks at me. Instead I thought we could do this, and Kevin let me know if you want to try it or have me do it. In the native code, after http returns successfully, write a variation of docCookie() in ebjs.c. This calls curl and asks for the latest batch of cookies, but you want to use window.location.href as your url. You'll get a string of cookies back, current and correct for this url, without the http-only cookies and using all the logic we already wrote, and then you just use set_property_string1(document.cookie, cookieList); But caution, remember to suspend the setters. We don't want to feed these cookies back into the jar, they're already there. suspend_setter = true; set_property_string1(document.cookie, cookieList); suspend_setter = false; Anyways I think that's the easy way to keep cookies consistent across xhr. Karl Dahlke