« XML PATCH | Main | AtomPatch, or: Composing Media Types »

Sunday, August 18, 2013

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Andreineculau

Are you saying that there would be lots of Accept-X headers? temperature, currency?

Just some quick thoughts, Erik, from my (one-sighted) realms:
- the majority of HTTP clients/server don't know how to parse/build headers in general, but predominantly content negotiation headers
- regarding caching, I hope I'm not wrong, but even a larger "majority" doesn't know of semantic equivalence, so Accept:x,y is not equivalent with Accept:y,x

At least that's where I'm stuck - and that's smth I'm trying to improve/fix in my own little corner of github.
Until there are proper HTTP parsers&builders, I can only tag amendments as "impractical" (don't get me wrong, I value the concept - but I'd like to build on a foundation that I can "touch").

dret

thanks for the feedback, andrei. what i am proposing is not not have specific "Accept-Temperature" and "Accept-Currency" headers, because header field names definitely should be fixed and not dynamic. that's why the header fields mentioned in the blog post are fixed, they are Accept-Axis, Content-Axis, Accept-Axes, and Content-Axes.
these proposed header field names are fixed, and identifying the actual negotiation axis is done by using axis identifiers (registered keywords or URIs) in these header fields. so all your HTTP header handling needs to do is parsing the header field value, and you can rely on the header field names being fixed.

Andreineculau

My apologies. I have no idea how I reached that conclusion, Erik.
But the rest still stands: Accept-Axis is a tad more complex than Accept[-*]/Content-*, and even Accept[-*]/Content-* is rarely implemented "correctly" (or as flexible as the ID specs it).

To be a bit more explicit and change my comment on the positive side
- what I personally like about your proposal is the abstraction level - I am biased in my liking because I thought about this when imagining some sort of an Accept-Currency header (I've been working in the finance industry) and then thinking why not just make content negotiation headers abstract from the "namespace" as I cold it (your "axis")
- I am 100% behind your proposal - given that the RFC comes not just with an ABNF grammar, but also with an AST structure to parse into and to build from, which sits at the core of the implementation of these headers

It is not as simple as to say "all you need to do is parse". Most RFCs start with the premise that it is the concept, the effects and the side-effects that are the hardest to nail - while implementation is just details, a hop with no quality check but just a quantity check (in a minimum number of implementation instances).

PS: A bit of context for my previously a-bit-harsh comment - I am on the path of trying to bring some sense (at least to me) into handling HTTP server-side at https://github.com/andreineculau/http-decision-diagram . But in order for that to happen, one needs to parse HTTP headers properly, which I try to do with PEGs (ABNFs are not enough for creating ASTs) at https://github.com/andreineculau/core-pegjs but even that is not enough, because one needs to also build HTTP headers (AST to string) and associate specific logic (e.g. Accept header selecting best match given the resource's provided content-types) which I try to do (for NodeJS) at https://github.com/andreineculau/api-pegjs .
So now imagine that I have all that on my hands, and I'm not far, but still considerably "not-close" from a clean ideal implementation :) and then I read about more headers. Hope you accept my sincere apologies both for my misunderstanding and my previous tone.

dret

again, thanks for the response. good to see we agree on the general idea. you're definitely correct that this idea is more complex than the "hardcoded" current content negotiation schemes. but i guess that's hard to avoid when the goal is to come up with something that should be more flexible than those headers. and i guess your "namespace" idea is pretty much exactly what i am proposing, only that the namespace i am suggesting has two distinct sets: the registered "simple values", and the unregistered URIs.
and of course if that were developed into a draft heading towards RFCness, then the header would need to specify a grammar in ABNF. but it seems to me that many pieces of that grammar are already existing in other headers (the "Link" header, the existing "Accept-*" headers), so it wouldn't be too hard to define such a grammar.
the "processing model" of that grammar would be what you refer to as the AST, i assume. the exact syntax and rules for how to encode and select variants in the proposed headers is not something that i would claim is fully specified in this little blog post. i was more wondering about the idea and its utility in general, and it seems like you can see some uses cases for yourself, which is encouraging. thanks for your comments!

The comments to this entry are closed.

Flickr