[http] require accept header?

[glasser]

I think this WG is mostly for the underlying spec changes, not the HTTP transport, so rather than have discussion about this here, I'm just calling out an issue on the graphql-over-http repository. I've recently added a comment to this old issue with my thoughts. The tl;dr: I think clients should send a header like accept: multipart/mixed, application/json and servers should not send multipart/mixed responses to clients that don't ask for it, and that they should send errors to those clients if they use an incremental delivery directive.

Issue comment: graphql/graphql-over-http#167 (comment)

[maraisr]

agree the content type should convey its responding with multipart contents! In fact meros will not process the response as multipart if the server didn't send it ~> https://github.com/maraisr/meros/blob/e63608b1926e7f8c7ab217b72bd9b425b274c305/src/browser.ts#L97

but vaguely remember there being chatter about the accept header, as in the presence of @defer should exist in the same space as the person making the call, and generally the network doesn't directly talk to the executor. So you'd have to strip the directives before giving it to the executor.

So 💯 about response types, but 👀 about accept header — imo. Think of it like, the user decides if it wants to defer, not the server. So if you defer, by virtue you accept as well.

my 2c

[maraisr]

The thing is executors and transports are specifically kept seperate, so to tie them together is a bad move.

At best, and not specifically a spec move imo — but a user land "recommendation" would be for the network to set an executor flag, say incrementalDelivery: false if the network deems necessary. Which afaik can be done today. As to say "if accept header not multipart, then executor you better not yield".

[glasser]

I'm not sure I follow your argument. In any case, can we take this over to the issue on the graphql-over-http repository as I suggested? This seems in line with your point that transport discussion should be kept separate from execution discussion.

[maraisr]

You don't seem to follow many things, maybe my bad. Quite frankly, accept headers and multipart guarantees is not something the executer should care about. If a server wants to disable that feature based on some signal (the lack of accept header), then so be it. But not something to be specified in the spec.

[glasser]

The spec I am talking about is this one which is all about headers and multipart formatting. (And it's an RFC for updating a larger spec which has plenty of thoughts about the Accept header specifically.)

[maraisr]

sounds to me like you're wanting to chat about transport specifics, as both of those links link away from this repo.

@robrichard do we have chatter about the transport here?