Subject: Formalizing the HTTP State Tokens proposal.

From: Mike West <[email-masked]>
Date: Thu, 28 Mar 2019 11:14:22 +0100

Way back in August, 2018, I started a thread [1] on a proposal to introduce
a client-controlled, origin-bound, HTTPS-only session identifier for
network-level state management [2].

I wasn't able to make it to IETF104, but I will be attending the HTTP
workshop next week. In the hopes of sparking some conversations there, I've
formalized the proposal as
https://tools.ietf.org/html/draft-west-http-state-tokens-00, clarifying
some pieces based on y'all's earlier feedback. I'm looking forward to your
feedback on, either here on the list, or at the workshop next week.

Thanks!

-mike

[1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0184.html
[2]: https://github.com/mikewest/http-state-tokens

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 28 Mar 2019 21:07:23 +0200 (EET)

5.1.  Attach HTTP State Tokens to a request
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-5.1

So Sec-Http-State header field is added also to requests for static sites, which do not need state.

Setting

Sec-Http-State-Options: delivery=same-origin

sure help reduce extra Sec-Http-State: header fields to be sent 
(for example static resources which are references on html page, 
 if they use another origin.)

However I suggest

Sec-Http-State-Options: delivery=none

so that static site can opt-out that request header.

Perhaps make sense also to defined other member for "Sec-Http-State-Options" header
dictionary, which controls which elements ('image', 'iframe', 'script', 'audio' 
and so on) cause Sec-Http-State: header field added to request when correspond resource
is retrieved. This is additional constrain (also "delivery" is in force).

Idea is further reduce http request size.

/ Kari Hurtta