- From: Mike West <mkwst@google.com>
- Date: Mon, 22 Feb 2016 12:57:45 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKXHy=dnKj4tzHxPnXPyZU2SkTEPve8fRbPs_CVpLYsR=h=X2Q@mail.gmail.com>
On Wed, Jan 20, 2016 at 5:25 AM, Mark Nottingham <mnot@mnot.net> wrote: > > > On 19 Jan 2016, at 7:52 pm, Mike West <mkwst@google.com> wrote: > > > > On Tue, Jan 19, 2016 at 1:14 AM, Mark Nottingham <mnot@mnot.net> wrote: > > Hey Mike, > > > > On 18 Jan 2016, at 8:09 pm, Mike West <mkwst@google.com> wrote: > > > > > > While we have the cookies spec open, I think we should take a closer > look at how that specification interacts with others. In particular, two > things come to mind: > > > > > > * We should formalize the integration with Fetch (see step 11.1 of > https://fetch.spec.whatwg.org/#http-network-or-cache-fetch and 9.3 of > https://fetch.spec.whatwg.org/#http-network-fetch). > > > > What changes in the RFC would be necessary to do this? > > > > This would boil down to: > > > > * a light refactoring of https://tools.ietf.org/html/rfc6265#section-5.2 > away from "When the user agent receives a Set-Cookie header field in an > HTTP response", towards something more like a "Process a `Set-Cookie` > header" algorithm that Fetch can pass the header value into explicitly. > > > > * A thin shim on top of the "cookie string" algorithm that actually sets > the header for a Request. This could live in Fetch, I suppose, but seems > better positioned in the Cookie spec. > > > > I can put together a brief I-D spelling out these changes. > > Please. > Taking another look at the text, I don't think this is worth doing in RFC6265bis. I've submitted https://github.com/whatwg/fetch/pull/221 to do the work in the Fetch specification instead. -mike
Received on Monday, 22 February 2016 12:03:43 UTC