Hi Marc,
>> IMO it is useful to require in section 3.7.2 "Request Matching", item
>> 3.a.2to define, that a runtime env must return all supported methods
>> in the "Allow" header
>> (http://tools.ietf.org/html/rfc2616#section-10.4.6)
> That is already specified in the HTTP RFC (a response with a 405
> status code requires an Allow header). I don't want to restate
> existing HTTP requirements in the spec.
Yes, I know. Ok, no problem.
>> IMO it is also useful to give the ExcpetionMapper the supported Media
>> Types, so that the ExcpetionMapper could create an entity with it
>> (see http://tools.ietf.org/html/rfc2616#section-10.4.7).
>> Unfortunately there is / are no header(s) defined by HTTP to support
>> this.
>> We could define a WebApplication subclass with a special attribute
>> for status 406, or a special header which contains this information.
> Its a pity there's no standard way of conveying that information. WADL
> would work for this purpose but it wouldn't be appropriate to require
> it in the JSR. For now I think we should leave this as an
> implementation detail.
The idea of the new WebAppExc approach was to give the developer a
possibility to develop it's own return entities. This requires an
standardized way, IMO. Because the spec defines, that the Response must
not include any entity (and this is useful), it is not possible to put
the supported Media types into the entity.
If every runtime env uses this only in its own implementation, than this
doesn't matter. But for compatibility reason their should be a default
way IMO.
best regards
Stephan