search

w3c / webappsec-fetch-metadata

Fetch Metadata
https://w3c.github.io/webappsec-fetch-metadata/
Other
75 stars 28 forks source link

Interaction with Structured Headers #40

Closed annevk closed 5 years ago

annevk commented 5 years ago

Currently Fetch only has an interface for setting headers with a value space as described at https://fetch.spec.whatwg.org/#concept-header. This means that saying a header is a Structured Header is meaningless for the purposes of Fetch. Setting values to strings is a type error.

Until HTTP proper has a notion of Structured Headers and can serialize them as needed for a connection/request-response we'll need to use https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#text-serialize somewhere. We could add an API in Fetch where you can manipulate a header list by passing it a Structured Header and then it runs serialize or you could call serialize here.

I don't really see Structured Headers helping out with this problem unfortunately and I do think it provides the necessary hooks to do what we want. Again, once it's a native part of HTTP and the HTTP data model we can do better as we don't have to worry in the Fetch layer about serializing a Structured Header, we can just pass it on to the HTTP layer and let it deal.

Hope this helps. All errors mine, hopefully @mnot has time to correct if needed.

mikewest commented 5 years ago

It's not clear to me from this issue whether you think the text in places like https://w3c.github.io/webappsec-fetch-metadata/#abstract-opdef-set-site is appropriate or not. Are there changes that you think would make it better in the short-term? Are there things you'd like to see change in Fetch that I could throw patches at you to address?

annevk commented 5 years ago

I'm sorry, I must have misread this initially. I think it's fine as-is, but the layering probably needs work at some point. In particular, I think we should have entry points for adding to a header list that take a Structured Header. Those entry points will initially serialize and, but long term would be able to preserve the fact that it's a Structured Header so the HTTP layer can take advantage. (Though maybe the HTTP layer will have knowledge of the Structured Headers anyway and parse and such optimizations are not observable so left to implementations to decide upon?)

Anyway, that's really more of a job for Fetch, though it should take inspiration from your work here.

mikewest commented 5 years ago

Would you like me to add a first pass at a "set a name/structured header value" algorithms to Fetch's header list, that just wraps the existing algorithms in a serialization step? Something along the lines of:

To set a name / structured header value pair to a header list list, run these steps:

  1. Let value be the result of serializing structured header value.
  2. Set name / value in list.

I'm not sure "append", "combine", etc. make much sense for structured headers, but I can add those as well if you think it would be helpful.

annevk commented 5 years ago

I think you're right that only "set" is reasonable. This would then down the line give us the ability to preserve more semantics.

Is it okay that values are used that are incompatible with the type-declaration of the name? Unless we want centralized lookup tables I guess that'd have to be okay, right?

cc @yutakahirano

mikewest commented 5 years ago

Put up a strawproposal at https://github.com/whatwg/fetch/pull/925.

mikewest commented 5 years ago

And yes, I don't think it's possible to do any type-checking given how things are currently structured. That seems like something we'll need to rely on error handling algorithms defined in Structured Headers and/or specific header definitions to deal with.

annevk commented 5 years ago

Yeah, I'm hoping we're not going to make the mistake again that you need to know about header names, but some of the implicit conversions and hop-by-hop renegotiation ideas leave me rather worried.