Re: JSR311: Limit extensions pre-processing

From: Dhanji R. Prasanna <>
Date: Wed, 9 Jul 2008 20:46:09 +1000

On Wed, Jul 9, 2008 at 6:52 PM, Marc Hadley <> wrote:

>> URI opacity is an external thing, URIs aren't supposed to be opaque to
> the server - much of this JSR is concerned with URI cracking on the server
> side. I don't understand what you mean by "disrupting URI opacity" in this
> instance.

All I mean is that a client is now required to know that deleting /blah.html
will also remove /blah.xml. The URI is no longer opaque to clients since
they must grok that /blah.xml and /blah.html are different representations
of the same resource.

I am also curious about what happens in the case of a not-acceptable content
type (406), strictly speaking this should be 404 for "/blah.[unknown-type]"
since the noun could not be represented (at all). Will re-sending the
request with a different Accept header result in a proper representation?
I.e. Will GET "/blah.html" with Accept text/xml result in an xml document?