Subject: Question Regarding RFC2616-14.1 Accept Header

From: Alex Crawford <[email-masked]>
Date: Thu, 31 Mar 2016 18:33:29 +0000

Hello,

First off, my apologies if this is the wrong list for this question, but I've
had a heck of a time trying to find someone knowledgeable on this topic.

I'm working on a utility that fetches its config via HTTP from a remote system.
The configuration language for this utility will evolve over time, so I need a
way for the utility to convey which configuration versions are valid. I'd like
to use the HTTP Accept header for this task and I think it would look something
like the following (broken across lines for readability):

   application/vnd.coreos.ignition+json; version=2,
   application/vnd.coreos.ignition+json; version=1; q=0.5

My intent is to convey to the remote system that this particular version of the
utility can accept version 1 or 2 of application/vnd.coreos.ignition+json, with
a preference for version 2. I believe this is syntactically correct, but I'm
wondering if it's semantically correct as well - am I abusing this
functionality?

Any insight you might have would be greatly appreciated. Thanks!

-Alex

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 2 Apr 2016 08:04:32 +1300

> wondering if it's semantically correct as well - am I abusing this

Extension parameters like 'version=DIGIT' are interpreted by the origin
server receiving them and should be passed-through by any intermediary
software. Beyond that the server implementation defines what the
semantics are - so it depends on whether you are coding for the server too.

But do not forget that HTTP contains caching. So your API definition
MUST send Accept back in the Vary header when doing this.

Using a unique URL for each config version and just fetching the desired
version would be best.

Alternatively; A custom header could be used instead of Accept. So you
can list it in the Vary header without causing the huge variant
permutation space that Accept will force on caches.

Alternatively; The User-Agent header is supposed to contain the name and
version of the software generating the GET message. Your server could
'know' what versions of config are able to be sent to which client
application version. So the User-Agent header of the GET message is
sufficient to find the resource to respond with. Vary would then need
User-Agent header listed.
 This method has similar permutation space issues to Accept. So is not
quite as good as it could be.

Amos