Re: JSR311: Limit extensions pre-processing

From: Dhanji R. Prasanna <>
Date: Fri, 4 Jul 2008 19:50:24 +1000

I heard this at a talk too, where someone from Microsoft represented the
JSR-311 EG's opinion as preferring the in-noun content-type. I have to say,
I for one disagree with this as a primary conneg system. Not the least
because this disrupts URI opacity.

I agree with Jerome that the convenience ought to be limited to safe methods
(GET, HEAD, etc.), if specified at all.


On Fri, Jul 4, 2008 at 7:37 PM, Jerome Louvel <>
> Hi all,
> In section 3.7.1 of the specs, the preprocessing of extensions for
> URIs is explained. The idea is to simulate content negotiation without
> having to specify actual Accept* HTTP headers. This is nice.
> As mentioned in HTTP 1.1 RFC: "The Accept request-header field can be used
> to specify certain media types which are acceptable for the response".
> Therefore it seems confusing to use the pre-processing for methods like
> POST, PUT, DELETE as it becomes impossible to act on a specific
> representation (identified as an independent resource).
> For example, let's say we have resource "/path/test" which is available in
> two media types, HTML and XML. It is nice to be able to GET
> "/path/test.html" or "/path/test.xml".
> But, if you want to delete only the HTML version, DELETE "/path/test.html"
> will actually become DELETE "/path/test" after pre-processing and actually
> delete the "/path/test" resource and ALL its representations.
> Therefore, I think the pre-processing should only be limited to safe
> like HEAD, GET and maybe to OPTIONS method as well.
> Best regards,
> Jerome Louvel