On Jul 9, 2008, at 12:46 PM, Dhanji R. Prasanna wrote:
>
> On Wed, Jul 9, 2008 at 6:52 PM, Marc Hadley <Marc.Hadley_at_sun.com>
> 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
header.
> 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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.