Closed theirishpenguin closed 10 years ago
If you omit the Accept header altogether, then the default version would still be served up, as there's no version being explicitly requested. In other words, no Accept header and an Accept header that doesn't contain a supported version string are essentially the same thing, and will result in the same behavior (version not found, serve up default if configured).
If you omit the Accept header altogether, then the default version would still be served up, as there's no version being explicitly requested.
That's cool, and I like this behaviour.
No Accept header and an Accept header that doesn't contain a supported version string are essentially the same thing
This is not the behaviour I'd expect. Let's say a third party dev is trying to call my API...
What do you think? Maybe it's just me :)
I would suggest you simply do not configure a default version if you're worried about this scenario. Without a default version configured, when they request application/blah.3
they'll get a routing error (i.e. 404). It will fail fast, and they'll know something is amiss, instead of being lulled into a false sense of security while they unknowingly hit the wrong version.
Sure. I'd like to have a default just to make it easy for someone to consume with needing to worry about Accept headers. I'll figure out a workaround. Thanks for the quick replies.
@theirishpenguin Did you find a workaround for this? I'm facing the same issue where I'd like to distinguish garbage Accept headers from the absence of an accept header.
@johnkelly I haven't worked with this stuff for a while. But I don't think I did find a workaround at the time.
Given the following route with a default, eg.
When I supply any garbage Accept Header (eg. application/garbage) it matches the default route version.
Is there a way to only match the default route version in the absence of an Accept header - so that it does not match in the presence of a garbage Accept header?