Bill,
FWIW, from a pure JAX-RS perspective, I do not see a reason why we should not support TRACE just because of someone's deficiency in a Servlet container implementation. TRACE is a valid HTTP method. I'm not aware of any restriction in that regard in Servlet spec either. Are you? TRACE support has been there in the JAX-RS 2.0 APIs for more than 2 years now!
Also, I do not buy the security issue arguments. There are potential security issues with all HTTP methods, including GET and POST that are far more severe and none of those is a reason to not support GET or POST. Unless there is a clear restriction in a Servlet spec, I would suggest you to fix the Servlet container implementation. This is exactly the case where we would be "restricting a specification because of perceived implementation details" , which as you correctly pointed out in another email thread, "is just wrong".
Marek
On May 21, 2013, at 2:04 PM, Bill Burke <bburke_at_redhat.com> wrote:
> Cross-site tracing is one:
>
> http://www.apacheweek.com/issues/03-01-24#news
>
>
> On 5/18/2013 4:06 AM, Markus KARG wrote:
>> I can't see how we should discuss this without provision of more details on
>> the security problems?
>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>> Sent: Freitag, 17. Mai 2013 22:30
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> Subject: [jsr339-experts] remove TRACE support
>>>
>>> I ran into a problem where our Servlet container does not support TRACE
>>> for security reasons. I'm wondering if we should remove TRACE support
>>> from the API, or, at least make it optional.
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com