Subject: cookie-radius / http-equiv="cookie"

From: Rafal Pietrak <[email-masked]>
Date: Wed, 13 Oct 2021 09:38:03 +0200

Dear Everybody,

Some time ago I've drafted a proposal for cookie-radius
(https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/). This was
not received well, so I've decided not to press the matter.

But, since then I've learned, that there is a (currently depreciated)
http-equiv.set-cookie <meta> tag attribute. Since this was implemented
in most browsers, may be an improved definition of it's semantics could
make it useful again.

This is what would be needed for the purpose of my initial usage
scenario of cookie-radius:

1. the http-equiv word should not read "set-cookie", but should be just
"cookie" to stand out from historic implementations.

2. this particular <meta> tag should be filtered away by "show-source"
browser command (as an optional feature, not required for its purpose).

3. the cookie value provided by this <meta> MUST NOT be attached to any
content that is automatically retrieved by a page download-completion
process ... meaning: this particular cookie should NOT be used
(available to the browser) until the entire page and it's content is
fully downloaded.

4. the cookie should (MUST) be included to all the requests, that the
browser make in consequence of any user action (a click, or a tap, or an
ajax action) WITHIN this page. Action that results in any network
request to the same host (an ONLY to the same host).

5. the cookie defined in a <meta http-equiv="cookie"> MUST NOT be shared
among windows or tabs. It MUST be available ONLY to the clicks on a page
that received this <meta>.

I would appreciate any opinions on such proposal.

With best regards,

-- 
Rafał Pietrak

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 24 Oct 2021 21:32:23 +1300

> in most browsers, may be an improved definition of it's semantics could

Please be aware that "http-equiv" META are expected to cause the Browser 
the same behaviour as if the key name (here "set-cookie") was a received 
HTTP header.

So your proposal needs to be made to change RFC 6265 as changes to the 
Set-Cookie and Cookie headers themselves.

Amos

---

From: Rafal Pietrak <[email-masked]>
Date: Sun, 24 Oct 2021 17:19:15 +0200

> the same behaviour as if the key name (here "set-cookie") was a received

Yes, I expect that. That's the reason, why I've suggested a change of
the actual name of the header line (to plain "Cookie") - to indicate the
requirement to "slightly" break the http-equivalence. (I've called it
"cookie" to stumble a "too direct" reading, not to suggest any actual
definition - that's to be worked out by the working group).

> Set-Cookie and Cookie headers themselves.

OK. Yes. Great. But is it possible? I'll be more then willing to help
work it out: cook the phrasing, provide arguments, analyse consequences,
etc.

With best regards,

-- 
Rafał Pietrak