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
//
