- From: Mike <mike@mykanjo.co.uk>
- Date: Tue, 18 Nov 2008 16:19:24 +0000
Hallvord R M Steen wrote:
>>>> "It's less typing" - Is that serious or are you joking?!
>>>>
>>>>
>>> Isn't it? :)
>>>
>>>
>> Well sure, but I still don't know if that was a joke or whether it was a
>> serious point!
>>
>
> A bit of both. It's not an important point by any means, though I
> think less verbosity is valuable :)
>
>
Having multiple URIs for different resources, when HTTP provides an
alternative - is another type of verbosity. I'd much rather have it in
the markup, personally.
>>> The language and even format of a resource is actually
>>> often essential to that resource's identity. (The whole
>>> content-negotiation idea is based on that statement being false. I
>>> believe it's true.).
>>>
>>>
>
>
>> Language is a separate issue from content type. I would consider a
>> translated document as a separate resource which should be indicated in the
>> URL.
>>
>
> OK, we agree here.
>
>
>>> For links *users* (and FWIW search engines,
>>> validators and other agents) may interact with it's however a big
>>> mistake to move away from one URL per variant of a resource. In light
>>> of my content negotiation experiments and experience I'd say an Access
>>> attribute in HTML would be harmful to the usability of URLs.
>>>
>
>
>> If your system is designed to provide several different content types for
>> users to be able to read/write/update/delete a single resource from various
>> different User Agents - it's totally misleading to provide a separate URL
>> for each of them.
>> If I update the information in /report.pdf - does that update the
>> information in /report.html and /report.xml ? They're seperate resources
>> (indicated by seperate URLs) so from a 'usability' point of view, the
>> expected result should be to *only* update that the information in
>> /report.pdf.. but that's not actually the case here since the system will
>> update the information in the other two URLs aswell.
>>
>
> It's an interesting use case. It's also a simple UI issue that can be
> solved on a UI level, if, say, my CMS shows that I'm about to update
> "/report" or lists the files that will be affected. So this use case
> doesn't need to be addressed at an architectural level where it will
> have negative consequences for the usability of URLs.
>
>
That doesn't sound like it will end up very "uniform"!
>> This kind of behavior *breaks caching*, for obvious reasons.
>>
>
> Caches have to check whether resources are fresh according to caching
> headers and/or settings anyway.
>
>
Don't reverse proxy caches automatically react to update the cache if a
PUT or POST is performed on a given URI?
>>> File types are all about convention. It's useful when sites follow the
>>> convention, and it's a surprise in the rare event when they don't.
>>> Since most of the time they do it's more useful than harmful.
>>>
>
>
>> What is the value of that 'convention'?
>>
>
> To me it's high, because it lets me E-mail/share URLs and be certain
> of what variant the recipient sees, and it helps me decide whether or
> not to open links I receive. ("Oh, that's a .ppt file - I don't have a
> viewer for that so I won't bother").
>
>
You can be certain by telling them which UA is appropriate - if it's the
same information but just in a different format, why does it matter that
the content-type is different?
>> It only exists because of the present insufficiencies of HTML to provide
>> browsers with a way to leverage protocol level conneg.
>>
>
> Perhaps, but it has proven valuable in many other ways.
>
>
What are you measuring that value against?
>>> My scepticism has nothing to do with whether it's easy to implement
>>> (though I think you underestimate the required efforts - for example
>>> the UA would need to verify that provided Accept: values are
>>> correct/don't cause security problems etc.). My scepticism has nothing
>>> to do with whether it is backwards compatible either. As a URL user I
>>> just want to defend the usability of URLs against a theoretically more
>>> pure but for practical purposes deeply flawed solution to a
>>> non-problem.
>>>
>
>
>> It's interesting you mention security actually. Right now - as it stands -
>> your web browser is sending all of its requests with an Accept header that
>> contains a catch-all "*/*". That is significantly less secure
>>
>
> This is incorrect. A malicious server can send you anything - no
> matter what the Accept: header (and the extension) is. Browsers have
> to deal with the fact that "anything" can come down the wire. (It
> would certainly be *nice* if malicious servers started respecting
> content negotiation and would stop sending you evil content if you
> stopped sending "*/*" in the Accept: header but something tells me
> things don't work that way).
>
>
>> - the fact
>> that you see .pdf at the end of the URL doesn't mean my server isn't about
>> to send you an executable. This is what I was referring to as "artificial
>> certainty".
>>
>
> If we implemented <a href="report" accept="application/pdf">report</a>
> the server could respond with an executable too. This argument is
> perfectly irrelevant to your case for HTTP-related attributes.
>
I agree, and it's in the rfc - that servers don't have to honor the
Accept header. It's certainly not any worse than URI conneg. Furthermore
- it's much easier for browser developers to create security mechanisms
against the standardised nature of Accept header and content-types; i.e.
if the content-type returned does not fit the Accept header of the
request then reject the response and notify the user of naughty behavior
from the server. This is much more difficult when you are doing conneg
in the URI because there are so many different ways of indicating to a
user what the content-type is that they are requesting:
/report.html
/report?type=html
/report;content-type=text/html
etc. etc.
HTTP conneg is much better suited for implementing security processes
like this because there is no ambiguity.
Regards,
Mike
//
Received on Tuesday, 18 November 2008 08:19:24 UTC