Interaction between Accept-Query and Allow

[hawkinsw]

Hello. I hope that these comments/questions are helpful. If not, please feel free to ignore them.

The QUERY extension says that a server may respond with an Accept-Query header whose value is a list of one or more content types it supports for encoding queries.

1. How does a server advertise its support for QUERY if it places no restriction on the content type? The grammar for the header value says that at least one content type must be specified.
2. Should we specify (for the sake of explicitness not correctness) how the Accept-Query header interacts/overlaps with Allow? In particular, does a 405 response that includes an Accept-Query header mean that QUERY does not need to appear in Allow?

Again, I hope that these questions are helpful. If they are, and there is a consensus on how to proceed, I would be more than happy to help draft some changed language. If these are not helpful, please just tell me to go away.

Thanks for your work on this interesting extension!

[martinthomson]

@hawkinsw (hi Will!) asks a good question here.

That made me ask something else:

1. Can we have an example of Accept-Query?
2. Can we have an explanation how Accept-Query compares to Accept in a response, and why there is a need for a new field for this purpose.

Of course, the real question is what Will asks: if the resource responds with 405 and lists a number of methods, how do you interpret the Accept/Accept-Query/Accept-Encoding fields of that response? It is entirely reasonable for a resource to support different media types for different methods.

One approach would be to say that managing the matrix of combinations is too difficult. These fields therefore only apply to the specific request that was made. That leads to Accept-* having no real meaning for a 405 response. Under that interpretation, I can't see any reason to define Accept-Query over a straight Accept. This is the most that RFC 9110 says, which isn't much.

[hawkinsw]

@hawkinsw (hi Will!) asks a good question here.

Hello back!!

That made me ask something else:

1. Can we have an example of Accept-Query?

2. Can we have an explanation how Accept-Query compares to Accept in a response, and why there is a need for a new field for this purpose.

I was wondering this very thing, too. Read what comes next with the caveat that I am not an expert at HTTP semantics but have started added QUERY support to freenginx:

It seemed to me that the Accept-Query response header would be good in a case where a client wanted to discover the server's preferred way of receiving a query. Say that, for example, a web application could accept queries via POST or QUERY but the QUERY used fewer resources (for whatever reason). The client could issue an OPTIONS request to see whether (and in what mime type) the server accepts QUERY requests. If the response did not include an Accept-Query header, the client could fall back to the other means of issuing a query.

Of course, the real question is what Will asks: if the resource responds with 405 and lists a number of methods, how do you interpret the Accept/Accept-Query/Accept-Encoding fields of that response? It is entirely reasonable for a resource to support different media types for different methods.

One approach would be to say that managing the matrix of combinations is too difficult. These fields therefore only apply to the specific request that was made. That leads to Accept-* having no real meaning for a 405 response. Under that interpretation, I can't see any reason to define Accept-Query over a straight Accept. This is the most that RFC 9110 says, which isn't much.

It does seem that there is a pretty interesting matrix of possibilities there. I think that the approach you outline is workable but ultimately it seems to depend on, as you said, whether or not there is an actual reason to define Accept-Query.

PS: A sincere thank you for validating that my question wasn't entirely stupid.

[MikeBishop]

You're correct that Accept-Query adds only one bit of information over Accept -- the fact that the QUERY method is supported on this resource. I'm inclined to say that requiring at least one content type is reasonable, since this is an object the server will need to interpret, not just store. (The same argument could be made for PATCH.) If the server must be able to read it, the server has a list of formats it can interpret, and that can't be wide-open.

Arguably, one could use Accept and then use Allow to advertise QUERY support.

[reschke]

Or we could just re-use the syntax for Accept (https://greenbytes.de/tech/webdav/rfc9110.html#field.accept) which would allow "*/*". And clients could just re-use their field value parser for "Accept".

@mnot - want to suggest SF syntax?

[mnot]

It's either a SF or not - you can't both define it as a SF and also re-use existing parsers.

If we go SF, it would either be a List of Strings or a List of Tokens (using Strings when the field name contains disallowed character).

[reschke]

In both case we would use existing parsers, no?

[mnot]

Yes, as long as it's the right one.

[nicowilliams]

Suppose you have a resource which allows PUT and QUERY meaning very different things, such that the sets of accepted request body MIME types for those two methods are disjoint, then Accept-<Method> might be a reasonable extension in general, and Accept-Query a reasonable extension in particular. Perhaps then Accept-Query should be generalized to Accept-<Method>.

[zenomt]

there are already Accept-Patch and Accept-Post response fields in the IANA HTTP Field Name Registry. i think Accept-Query is valuable for the same reasons those other Accept-<method> ones are, and that its value should be 1#media-type, both for consistency with Accept, Accept-Patch, and Accept-Post, as well as to allow media-type parameters along with the principal type/subtype.

the use case i'm envisioning is advertising support for, say, specialized profiles of a media type, like for example

Accept-Query: application/ld+json; profile="http://zenomt.com/ns/jsonld-terse http://example.com/ns/terse-query"

[martinthomson]

I would prefer SF with List of Tokens (with a string fallback for things like the one below).

It's entirely possible to reuse Accept parsing, but there are things that we don't need from that, like q-values, such that it would be cleaner to just list the acceptable media types. SF is purpose-built for that.

That means:

Accept-Query: "application/ld+json; profile=\"https://...\"", application/json

Parameters outside of the string would have no semantic. Media type parameters go inside the string because they are part of the media type. It's nice how Token includes "/", enabling this use case.

[reschke]

OK, we have two discussions here:

1. Do we need Accept-Query, and
2. If we do, what should be the syntax?

I propose to open a separate ticket for 2); and then we can concentrate on 1) first.

[martinthomson]

Given the activity on the draft, I had assumed that the first was already decided in favour :) Happy to be corrected.

The use case seems fairly solid. It doesn't sound super important, but the definition of a field seems cheap enough that the outcome is worth the price.

[reschke]

Summarizing: we seem to be in agreement that Accept-Query is useful.

Open questions:

• how does a server say that it supports any format? Does this make any sense at all? We currently require one value, and IMHO we can stick with that.
• format; I have opened a separate ticket for that: query: format for Accept-Query field #2934

[mnot]

I think this issue can be closed now.