On 8/1/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi, > > > > > Not necessarily. The HTTP spec mentions headers explicitly for content > > > negotiation > > > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html) > > > and there might be enough cases where a resource (!) happens to have a > > name > > > ending with .html without implying that it is actually HTML. The server > > > selects the representation that is being sent and the server determines > > how > > > to value headers or not. > > content negotiation is certainly an interesting capability, but IMO > > poses a lot of problems. for example, i don't want another > > representation of a document (for the same url) just because my > > browser locale is different. if the urls are not stable, the documents > > can't be cached, which is bad. > > > > Correct, but we are talking about POST, PUT and DELETE requests that are not > being cached, so that does not matter. > > > > > > > it's very logical, that a foo.html and foo.pdf are different > > > > representations of the resource foo. > > > > > > > > > > Only if you forbid having foo.pdf and foo.html as two different > > resources > > > in the same path. In that case you would have foo.pdf.html and > > foo.html.pdf > > > and foo.html.html and foo.pdf.pdf. > > which i would find very confusing. > > > > Then we should forbid JCR nodes with a dot in the name. This would mean > there are certain applications, where I cannot use Sling anymore, for > instance because it is impossible to get an HTML preview of a PDF or an XML > with extracted XMP metadata for a JPEG, but it might be less confusing. I > wonder how you could fulfill anything except a narrow set of requirements > with these restrictions. > > > > > > I have read this before, but I still do not understand why. You mention > > not > > > a single real use case that would be broken through my proposal. > > as i said, i fear problems if non-existent and existent resources are > > treated differently. > > > > What are the problems that you fear? Fear, uncertainty and doubt are no good > basis to brush away my valid requests for a broken behavior. > > Furthermore, we are not treating existent and non-existent resources > differently. You POST, PUT, DELETE to the base URL of the resource, you GET > from the base URL plus selectors and extensions. This is not treating > existent and non-existent resources differently, it is treating GET requests > differently, which is a good thing and something we are doing anyway (or > where is POST.html.esp) but the patch in your jira issue treats them differently.
if you're talking about always addressing the 'resource' in a POST request, then there is another problem, that you can't create any selector, or extension servlets anymore. regards, toby
