Pin the supported defer specification version to 20220824

[Geal]

Fix #1648
Fix #1656
Fix #1659

Pinned to this commit:
graphql/graphql-spec@01d7b98

Since the router will ship before the @defer specification is done, we
add a parameter to the Accept and Content-Type headers to indicate
which specification version is accepted

[abernix]

Can we return an HTTP 406 with the error case?

[prasek]

Suggested change

	pub(crate) const MULTIPART_DEFER_SPEC_VALUE: &str = "20220824";
	pub(crate) const MULTIPART_DEFER_SPEC_VALUE: &str = "20220822";

clients are sending deferSpec=20220822 can we use that instead?

• see related Response to Deferred Query with Accept: multipart/mixed is application/json #1656

[abernix]

@prasek The motivation for picking 20220824 as the value seems justified/warranted since, as noted above, we're pinning to a commit of the specification on August 24th. If we're going to have a deferSpec that looks like YYYYMMDD then it should probably match the spec as of that date. I think clients should make the change here even though I realize this is a bit of a moving target at the moment. It should settle down soon.

On the other hand, if we want a bit more flexibility here (there is probably flexibility) perhaps we should choose a deferSpec that isn't so precisely date-based — like 202208.001.

[abernix]

Personally, I feel like the clarified behavior in that defer spec commit referenced above is noteworthy and worth abiding by, but if we agree together that it's not then let's ensure our implementation (on both sides) abides by the specification on the 22nd.

[Geal]

the changes to the defer specification from August 24th are used in #1640 so that will be the version we use, because we need the clarification on the if argument default behaviour

[abernix]

Cool. We can communicate that to the client teams. Thanks!

[prasek]

sounds good 👍

[abernix]

A comment from @glasser in #1656 (comment)

                list.any(|mime| mime.as_ref() == Ok(&multipart_mixed))

This Eq check compares to see if the types are exactly the same including parameters. You probably want to check to see if mime.essence() (which is the type without the parameters) equals multipart_mixed (and then of course look for deferSpec too).

Referring to:

router/apollo-router/src/services/supergraph_service.rs

Lines 308 to 321 in cf40d8d

	fn accepts_multipart(headers: &HeaderMap) -> bool {
	let multipart_mixed = MediaType::new(MULTIPART, MIXED);
	headers.get_all(ACCEPT).iter().any(|value| {
	value
	.to_str()
	.map(|accept_str| {
	let mut list = MediaTypeList::new(accept_str);
	list.any(|mime| mime.as_ref() == Ok(&multipart_mixed))
	})
	.unwrap_or(false)
	})
	}

[Geal]

Can we return an HTTP 406 with the error case?

yes, it is done in c8a009e

[Geal]

A comment from @glasser in #1656 (comment)

fixed in e3752f3

[glasser]

FWIW my impression is that this particular library separates out "the thing after the +" so this woudl also match multipart/mixed+foo which is probably not ideal. I would suggest just doing mime.essence() == multipartmixed (essence strips parameters)