Skip to content

Convert Variants to use Structured Headers.#744

Merged
mnot merged 3 commits into
httpwg:masterfrom
jyasskin:structured-variants
Jan 7, 2019
Merged

Convert Variants to use Structured Headers.#744
mnot merged 3 commits into
httpwg:masterfrom
jyasskin:structured-variants

Conversation

@jyasskin

Copy link
Copy Markdown
Contributor

Fixes #570. I think this also fixes #743, but I might have missed something.

Misc changes that aren't actually necessary to use Structured Headers:

  • "variant-item" became "variant-axis".
  • I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs.
  • I removed the (incorrect) token / "/" / "?" / "\" / "[" / "]" / ":" / "@" / "(" / ")" definition of available-value in favor of allowing arbitrary Structured Header strings. It wasn't clear what excluding characters like { was gaining us, and the restriction would have required extra words when parsing the headers.
  • I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of Variant-Key. It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces.
  • I simplified Compute Possible Keys a bit.

@jyasskin jyasskin force-pushed the structured-variants branch 2 times, most recently from de8e409 to 59e6719 Compare January 3, 2019 00:39
Comment thread draft-ietf-httpbis-variants.md

@mnot mnot left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good; just one immediate issue I can see (although I might tweak some once it's in).

Thanks!

Comment thread draft-ietf-httpbis-variants.md

indicates that this response can be used for requests whose Accept-Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" -- perhaps because there is no gzip-compressed French representation.

When more than one Variant-Key value is in a response, the first one present MUST indicate the variant-key for the response it occurs within.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requirement addresses an implementation constraint; if they can't easily link a response to multiple potential requests, this allows them to still behave correctly (if not optimally). Why did you remove it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember exactly what I was thinking, but it seems redundant right now. All of the variant-key values are variant-keys for the response they occur within, so of course the first one is also a variant-key for that response. Do you mean that the first variant-key list item should be the "best"? And that caches MAY discard subsequent ones?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wording above doesn't reflect the intent well. It should be:

When more than one Variant-Key value is in a response, the first one present MUST correspond to the request that caused that response to be generated.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes sense. I've added your wording back.

I think it could be wordsmithed a little better now that Variant-Key is a structured header, but I don't want to delay merging the overall change. Specifically, "more than one Variant-Key value" implies to me that the Variant-Key header appears more than once, but we actually mean that the list parsed for Variant-Key from a response contains more than one inner-list, even if they're all parsed from a single instance of the header.

@mnot mnot added the variants label Jan 4, 2019
@jyasskin jyasskin force-pushed the structured-variants branch from 59e6719 to fd98d61 Compare January 4, 2019 17:41
A response's request's key must be listed first.
@mnot mnot merged commit dd19a76 into httpwg:master Jan 7, 2019
@jyasskin jyasskin deleted the structured-variants branch January 7, 2019 03:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

Cache behavior examples are out of date wrt new Variant-Key format Adopt Structured Headers

2 participants