Re: JSR311: Limit extensions pre-processing

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 09 Jul 2008 13:08:04 +0200

On Jul 9, 2008, at 12:46 PM, Dhanji R. Prasanna wrote:
> 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.

Jerome was arguing the opposite, that you could delete blah.html but
leave blah and blah.xml unchanged.

> 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.
An application can provide that information via a Content-Location

> 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).

Yes, you would get a 404 since the unknown extension wouldn't be
removed and the URI would then not (presumably) match any resource.

> 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?
The extension overrides the accept so GET /blah.html will get whatever
media type .html is mapped to by the application.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.