[jax-rs-spec users] Re: Allow header discrepancy between _at_OPTIONS request and 405 Method Not Allowed exception

From: Paul Moore <>
Date: Thu, 18 Jul 2013 16:28:31 +0100


Many thanks for this, I will raise a JIRA as you suggest. I wanted not to
have have missed something obvious!

I was thinking that there might be a more general requirement for
delegation of other header values e.g. ETag's, although some have more
"resource affinity" than others.

With some thoughts towards a solution I was considering an annotation based
approach (e.g. @Header(value="Allow) ) to annotate the delegate methods,
but I'm cognisant of the fact that *a* resource may be split across many
classes (as with method requests), so there may be a requirement for an
equivalent to the Method Router in order to dispatch to the appropriate

Anyway, I'll raise a JIRA for the Allow header case and see where we go
from there.

With regards to progressing a solution, is this the best forum to continue
the discussion?

Many thanks


On 18 July 2013 16:00, Santiago Pericas-Geertsen <> wrote:

> Paul,
> Seems like a reasonable request to me. I suggest that you file a JIRA [
>] if you haven't done so yet.
> Thanks.
> -- Santiago
> On Jul 17, 2013, at 12:03 PM, Paul Moore <> wrote:
> Hi all,
> I'm after some help with potential discrepancies in the Allow header of a
> particular resource.
> I (reasonably) have a resource which "Allows" different methods at
> different points in its business lifecycle.
> By way of (contrived) example, imagine a shopping cart which only allows a
> maximum of 10 items in it. The (cart sub-ordinate) items collection is
> POST accepting up to the point at which it has 10 items, at which point it
> is no longer POST accepting. The point here is that the "Allow"able
> methods on the collection can change with the business state. Accordingly
> an OPTIONS request should reflect the change in resource state i.e. for
> I understand that:
> i) I can set the Allow header appropriately in the ResponseBuilder (for a
> matched method), and
> ii) I can can create an @OPTIONS annotated method that implements
> the vagaries of the resource lifecycle, and
> iii) the "implementor" is responsible for providing generated Allow
> headers in a) 405 Method Not Allowed exceptions, and b) OPTIONS request
> where no @OPTIONS annotated method has been provided.
> In the Jersey implementation, the automatic Allow header is (reasonably)
> generated by reflection of the annotated methods for the resource. This
> approach obviously limits the result to *static* annotations.
> My point here is that whilst the spec provides for customisation of the
> Allow header for the @OPTIONS request, it does not provide a mechanism to
> allow users to supplement the automatic "Allow" generation functionality,
> and therefore the user is subject to the implementation as to whether these
> match.
> Explicitly, given the Jersey example, I can easily customise the @OPTIONS
> request response, but 405 handling is buried deep within the
> (internal) MethodSelectingRouter::getMethodRouter, leading to discrepancies
> between the dynamic @OPTIONS handling and the *static* 405 handling.
> So, aside from extending Jersey in some way to handle this "dynamic
> resource" (a discussion for another forum) I am wondering if a future
> revision of the spec could or should mandate some pluggable delegation
> mechanism for handling Allow headers.
> Thoughts?
> Best regards
> Paul