search

httpwg / http-extensions

HTTP Extensions in progress
https://httpwg.org/http-extensions/
439 stars 146 forks source link

query: format for Accept-Query field #2934

Open reschke opened 3 days ago

reschke commented 3 days ago

1) "#mediatype (for consistency, for example, with PATCH: https://greenbytes.de/tech/webdav/rfc5789.html#accept-patch) 2) Structured Fields, because that's how we define new fields (and one could argue that we shouldn't make up reasons not to use that format)

My proposal is 2).

Acconut commented 3 days ago

I'm also in favor of 2).

darrelmiller commented 16 hours ago

I am in favour of 2)

reschke commented 16 hours ago

We'll use SF in the next draft, and see whether somebody complains...

zenomt commented 9 hours ago

sorry for not chiming in sooner. i'm in favor of (1) #media-range (not #media-type, to allow for wildcarding), both for consistency with Accept, Accept-Patch, and Accept-Post, as well as that if it's a structured field with a list of tokens (as proposed by Martin), then a media type and its parameters is essentially an opaque string, and

application/something; param1="foo"; param2="bar"

would be distinct from

application/something; param2="bar"; param1="foo"

even though they are semantically the same, and still require parsing a media-range out of the SF value.

reschke commented 9 hours ago

Good point. @martinthomson - why exactly would you want the parameters be part of the string item? That would make parsing harder than it has to be.

(I assume there was a good reason for your proposal, but which?)

zenomt commented 9 hours ago

notwithstanding the issue with parameter order i just mentioned, if this is a structured field, then you need to do the SF parsing to get tokens, and then parse each one as a media-range anyway. so why not just media-ranges without an extra SF wrapper?

reschke commented 8 hours ago

One reason we (for some value of "we") prefer SF is that we've been consistently telling others not to define new fields in a non-SF syntax - even for consistency with other existing fields.

zenomt commented 4 hours ago

my reading of RFC 9651 suggests that a SF that is a List of Token Items (each of which can be parameterized) is syntactically equivalent (and mostly semantically equivalent) to #media-range (from RFC 9110). that is

Accept-Query: application/something; param1="foo", application/other; profile="bar"; param="baz"

conforms to both #media-range from RFC 9110, and sf-list from RFC 9651 where the sf-items are sf-token parameters.