Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
On Mon, 17 Nov 2008 m...@mykanjo.co.uk wrote: I've read that HTML5 will be providing markup for the PUT and DELETE methods. This is definitely good news - but I considered something else recently that, from what I can gather, is not in the current spec for HTML5; markup for specifying appropriate Accept headers for requests. What problem would such a feature solve? I brought this up recently in #whatwg on freenode, and I was informed that this is not currently being considered since the equivalent can be achieved by a URL parameter such as '?type=application/xml'. Many would not Accept (pun intended - sorry) that this method was significantly different, some even went as far as to suggest (disturbingly) that serving multiple content-types from the same URI is undesirable! Indeed, content negotiation on the Web has not been a particularly roaring success, and it would probably have been better if we had avoided intoducing it, but that's an issue for another working group (and another era, probably -- we're likely stuck with it now). On Mon, 17 Nov 2008, Adrian Sutton wrote: I don't see why the Accept header when following links or requesting images should be controlled by anything other than the browser. It's the browser that has to decide actually render the returned content so it's in the best position to decide what it can accept, not the page author. That does seem like a valid point. On Mon, 17 Nov 2008 m...@mykanjo.co.uk wrote: as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. A browser is a special case in which many different content-types are dealt with. The same benefit is not achieved if the content is negotiated via the URL, since the user would have to know the type their user agent required and modify the URL accordingly: example.com/report?type=application/rss+xml To me, this is a much cleaner and more appropriate use of a URI. Not to mention more user-friendly. Something, I believe should be encouraged - this is why I feel it would be an important addition to HTML5. People do this today: a href=http://example.com/report.html;html report/a a href=http://example.com/report.pdf;pdf report/a a href=http://example.com/report.xml;xml report/a ...with the e-mail just saying: http://example.com/report ...and Apache's content-negotiation module working out the best file to return. This works today, what's the problem with it? (Other than theoretical purity concerns, which have been argued both ways here and are thus not a useful criteria to evaluate solutions by.) On Mon, 17 Nov 2008, Adrian Sutton wrote: The reason this is basically never used today is two fold: 1. It requires correctly configuring the server, beyond just putting files on the file system. Very few people actually do this. 2. It requires the user to see a URL and decide that they want to paste it into Acrobat instead of their browser, without any indication that it would actually work. Indeed. Content negotiation is not really compatible with the mental model people have of URLs (which is more similar to their model of files than to the model that URIs really represent). On Mon, 17 Nov 2008, Smylers wrote: m...@mykanjo.co.uk writes: So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. Except that in practice on receiving a URL like the above, nearly all users will try it in a web browser; they are unlikely to put it into their PDF viewer, in the hope that a PDF version of the report will happen to be available. Indeed. A browser is a special case in which many different content-types are dealt with. It's also the most common case. Supposing I opened the above URL in a browser, and it gave me the HTML version; how would I even know that the PDF version exists? Suppose my browser has a PDF plug-in so can render either the HTML or PDF versions, it's harder to bookmark a particular version because the URL is no longer sufficient to identify precisely what I was viewing. Browsers could update the way bookmarks work to deal with this, but any exterrnal (such as web-based) bookmarking tools would also need to change. Or suppose the HTML version links to the PDF version. I wish to download the PDF on a remote server, and happen to have an SSH session open to it. So I right-click on the link in the HTML version I'm looking at, choose 'Copy Link Location' from the menu, and in the remote shell type wget then paste in the copied link. If the link explicitly
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hallvord R M Steen wrote: I've built two-three websites that use content/language negotiation and I now consider it an architectural mistake to rely on negotiation because the URLs no longer uniquely identify the variants I in many scenarios need to identify. It's OK-ish to do it as a pure format choice where the server and UA just agree on using the PNG or GIF version for an IMG tag. 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. As a URL user (web browsing human, HTML author, linker, bookmarker, E-mail-with-links author) I often want to be sure about what variant of a resource I link to. To be explicit about this across scenarios requires explicit URLs with language and type information. Agreed. I think the assumptions underlying content negotation are flawed, and thus the mechanism itself is flawed and causes confusion and inconvenience when used in practice. The sentiment underlying this proposal seems to be that HTTP content negotation would work fine if only the pesky browsers would support it, but I think there are deeper-rooted problems than simply a lack of browser support. I think a better solution is to publish the HTML version with attributed hyperlinks, like this: link rel=alternate type=application/pdf href=document.pdf or, if you prefer: a href=document.pdf rel=alternate type=application/pdf PDF Version /a This way clients can discover the alternative representations, but the alternative representations are all directly addressable so you can link to a specific representation. This approach is used in practice successfully today to make available Atom representations of HTML pages across the web. Atom feeds are arguably the best example of a successful completely-RESTful API that we have today, so this approach is proven to work. In future, once IETF has finished specifying this, it may also be possible to do this in the HTTP response headers for non-HTML resources: Link: document.pdf; rel=alternate, type=application/pdf (or something similar) ...and some other document formats such as Atom already provide equivalent linking constructs that you can use today.
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
On Wed, Nov 19, 2008 at 2:22 PM, Mike [EMAIL PROTECTED] wrote: Thomas Broyer wrote: On Tue, Nov 18, 2008 at 11:52 AM, Mike [EMAIL PROTECTED] wrote: Thomas Broyer wrote: On Mon, Nov 17, 2008 at 6:31 PM, [EMAIL PROTECTED] wrote: - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. How about other representations? (I know we're discussing HTML here, and not HTTP, but what if a resource has no HTML representation? are you proposing adding this capability to PDF, MSOffice, OpenDocument, et al. too?) That's an issue at the application level; RSS would work fine in that situation - any form of hypermedia will serve that purpose. How would RSS work better than HTML (as of today; i.e. without your proposed extension)? RSS wouldn't work better - you asked for another way of doing this without HTML, not a better way. By RSS would work fine I understood that RSS link mechanisms already match your needs in some way (which I know is wrong). You're saying that HTML fails to provide a mean for controlling the message control data to use Fielding's words (though restricting it to the Accept HTTP request header field) and when I ask for how other media types would work (or fail, actually), your answer is RSS would work fine. You lost me. Because HTML is presently insufficient in providing a mechanism for browsers to perform protocol level conneg.. it's been moved into the URI and each representation is provided as a separate resource. This clearly breaks the intended definition of a URI - this is why I don't consider browsers to conform to HTTP; since they force developers to misuse that part of the protocol. If you want to precisely identify the PDF version of that document, you need another resource (whose representations is a set with a single value: PDF). If your URI idenfies this document, you cannot blame anyone but yourself for not being able to identify this document in PDF. If you want to precisely identify the PDF *representation* (version) of that *resource* (document), you need the URI and your Accept headers set correctly. We're not reading the same definition for resource then... REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created. It is then left to the author to ensure that the identifier chosen for a reference does indeed identify the intended semantics. -- Roy T. Fielding, §6.2.1 of his well-known dissertation If your intention is to link to the PDF version of 'some concept', then you need an URI to identify it. To that end, the solution to this problem would be to put example.com/document into a PDF reader. Or if you were writing an HTML page, and you wanted to indicate in the a tag that the browser should specifically request the PDF representation, you include an Accept=application/pdf attribute. How about other message control data? (other Accept-* HTTP request header fields, but not only, as server-driven conneg is not limited to those Accept-* headers) And if WAKA http://en.wikipedia.org/wiki/Waka_%28protocol%29 finally make it one day, you'll have to amend HTML (and all other formats where you added those things that you're proposing we add to HTML) to take it into account. (by chance, HTTP is one of the only ReSTful protocol --well, it's just a protocol, you still have to follow the other ReST constraints) Anyway, we're going real far from this WG's scope, so I propose we follow up in private, or, even better, you re-hash the debate on the rest-discuss list or with Roy T. Fielding if you want. I completely agree that discussion is outside of the scope of this WG. That is one of my main points here; It's a design decision that you are taking out of the hands of developers by not provisioning the mechanism for. I don't consider well thats how its done and I don't think we need to do it any other way an acceptable response, since it *is* outside of the scope of the WG and is a completely subjective standpoint. Not to mention that your opinion suggests that HTTP conneg has no practical use, which I find hard to believe - feel free to explain why this is the case rather than just explain that it isn't used at the moment, I know it isn't! Don't get me wrong, I'm all for using conneg when appropriate [1, 2] and AFAICT the W3C uses it itself for its TRs. Yet, I'm not saying that's how it's done yada yada yada, on the other hand I do believe that you are wrong considering hypermedia consists of both a resource identifier *and* message control data. [1] http://intertwingly.net/wiki/pie/PaceContentNegotiationSection [2] http://www.imc.org/atom-protocol/mail-archive/msg05441.html OK.. Why would you not want to do everything you could to support all of the aspects of HTTP, particularly when you are being
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Thomas Broyer wrote: On Mon, Nov 17, 2008 at 6:31 PM, [EMAIL PROTECTED] wrote: Would the sender of that link necessarily know all the formats the URL provides? Anyway, that's an unrealistic amount of typing -- typically round here people just copy and paste a URL into an instant message and send it without any surrounding text. Whereas without any other information, people will generally open URLs in a web browser. So it'd be faster just to send the URL of the page which contains hypertext links to all the formats; at which point we no longer care whether those links specify the format in the URL or elsewhere. - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. How about other representations? (I know we're discussing HTML here, and not HTTP, but what if a resource has no HTML representation? are you proposing adding this capability to PDF, MSOffice, OpenDocument, et al. too?) That's an issue at the application level; RSS would work fine in that situation - any form of hypermedia will serve that purpose. What is the point of doing it in HTTP if it's being done in HTML anyway? - Nothing is 'done' in HTML, it's a markup language. It's being done (at the moment) in the URI. HTTP provides conneg, why would you consciously deny developers the opportunity to use it in browsers? Unless HTML5 provides the markup, this isn't possible. This means Browsers don't have the ability to fully support HTTP without having to use JavaScript rubbish; there is a window of opportunity to change this with HTML5. No. Browsers fully support HTTP in the sense that they send an Accept header dependent of their *capabilities*. If you want client-driven conneg, then use agent-driven/transparent (RFCs 2295/2296), not server-driven conneg. This is explicitly noted in RFC 2616 that server-driven negotiation has limits and can be disadvantageous depending on your needs. http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12 My argument is to provision both and let developers decide. True. But if the current way of doing it is good enough, there's no incentive to change. - Define 'enough'..! I don't know why/how you get the authority to make that assumption! And before you say it; I'm not assuming any authority myself - I'm trying to encourage you to help browsers conform to the protocol they make use of. Maybe you could explain how browsers do not conform to HTTP? (and no, HTTP does not mandate user-agents to give the control of the Accept-* headers to the user or the... server?!) URI = Uniform Resource Identifier A given document available in html, pdf, xml - is one resource. The various content types are representations of that resource. Because HTML is presently insufficient in providing a mechanism for browsers to perform protocol level conneg.. it's been moved into the URI and each representation is provided as a separate resource. This clearly breaks the intended definition of a URI - this is why I don't consider browsers to conform to HTTP; since they force developers to misuse that part of the protocol. Having to use a JavaScript virtual machine to perform PUT and DELETE is yet another example of this. There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the servers the ability to describe the available variants of a given resource in a content-type independent way. You'd rather push browser vendors to implement TCN/RSVA than HTML5 to add a content-type dependent equivalent. See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5 I don't really understand the point your making.. I would just like to see a way by which developers can link to *resources* with URIs and specify the representation if and when necessary for a given link. There is no choice at the moment because HTML is insufficient. An optional Accept attribute would address this issue and still allow for the current methods that you feel (subjectively) are 'sufficient'. - I'll say it again: I'm encouraging you to help browsers become better HTTP clients; surely that is high on the agenda here.. right?! No, we're discussing HTML and some Web APIs here, not HTTP. So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper Text are not closely linked? If you aren't discussing it that way; it might be worth considering, no? Or what about if I wanted to mail somebody pointing out a discrepency between two versions of the report, and wished to link to both of them. That's tricky if they have the same URL. Possibly I could do it like you have with the wget command-line above, but that requires me knowing which browsers my audience use and the precise syntax for them. - separate versions are separate resources, not separate content types. That has nothing to do with conneg.. s/version/variant/ Variants still need be
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Smylers wrote: [EMAIL PROTECTED] writes: Would the sender of that link necessarily know all the formats the URL provides? Anyway, that's an unrealistic amount of typing -- typically round here people just copy and paste a URL into an instant message and send it without any surrounding text. Whereas without any other information, people will generally open URLs in a web browser. So it'd be faster just to send the URL of the page which contains hypertext links to all the formats; at which point we no longer care whether those links specify the format in the URL or elsewhere. - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. Indeed it could. In which case the original claimed advantage of the recipient of the message being able to open a single URL in one of several different sorts of user-agents is no longer relevant; the links could specify the format in the URL and this'll work just fine. You're completely missing my point here. I'm well aware that you can do conneg in the URL. HTTP provides a way to perform conneg at the protocol level; no mechanism for this is currently provided by HTML. What is the point of doing it in HTTP if it's being done in HTML anyway? - Nothing is 'done' in HTML, it's a markup language. It's being done (at the moment) in the URI. Sorry; that was what I meant. Uniform *Resource* Identifier - different content types are different *representations*, not different resources. Protocol level conneg was included in HTTP so that URI's would not have to be responsible.. unfortunately HTML didn't provide adequate mechanisms to make use of this - so everyone is used to conneg happening in the URI. That doesn't make it 'the right way to do it'. Developers should be given the option. HTTP provides conneg, why would you consciously deny developers the opportunity to use it in browsers? HTML 5 implicitly denies things merely by not providing them. And it provides things which are useful. So the question actually needs to be asked the other way round: what benefits are there in this being supported? The benefits? Oh I don't know.. a markup language that supports the transfer protocol it runs on?! This isn't a feature request - it's a bug. You're denying developers the ability to choose to use protocol level conneg. Not just browsers, as I pointed out. Also many databases which have tables with URL fields would need extra fields adding. - I suggested the attribute should be optional, so it would make no difference; one would simply avoid using it if it was a big problem. If my database contains URLs of external websites, then it isn't under my control as to whether this feature gets used. If those sites start using it, then my URLs are no longer sufficient to uniquely identify what is downloaded, and I need to change my database schema (and software that uses it) to remedy that. They are completely sufficient, if you provided the link but with no Accept attribute specified.. it would use the browser default (which is, generally, html). So that's a non-issue; It's backwards compatible. True. But if the current way of doing it is good enough, there's no incentive to change. - Define 'enough'..! I don't know why/how you get the authority to make that assumption! I don't, of course! But then, I never made that claim anyway; I said _if_ it's good enough. That is, in order to make this change let's first show that the current way isn't good enough. It's not good enough because it's merging representations (conneg) into resources (URIs). This isn't the way HTTP was intended to be used, that's just what people are used to. I'm not suggesting the current way of doing it should be abolished, I'm saying we should give people the choice. There is no choice at the moment (aside from using JavaScript). You're forcing me to repeat myself alot! And before you say it; I'm not assuming any authority myself Good; the editor has a policy of ignoring appeals to authority! Like removing the ability to leverage protocol level conneg on the basis that it works fine in the URI, for example? There's little point in making browsers implement extra functionality and inventing new mark-up and evangelizing it, only to end up with the same functionality we started with; there has to be more. And the greater the effort involved, the greater the benefit has to be to make it worthwhile. - I'll say it again: I'm encouraging you to help browsers become better HTTP clients; surely that is high on the agenda here.. right?! Why? That's tantamount to an appeal to authority. Fully supporting HTTP is a means rather than an end. Are there situations in which supporting this particular part of HTTP provides additional benefit to users? Or are there many instances of authors tediously coding the same thing
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hallvord R M Steen wrote: Sorry, both as an author and as a user I'd prefer this: a href=http://example.com/report;html report/a a href=http://example.com/report.pdf;pdf report/a a href=http://example.com/report.xhtml;xml report/a - Keep It Simple. For me as an author it's less typing, and for me as a computer-literate end user it's clear whether a link is going to make me wait for Acrobat loading or open directly - even if the link is taken out of the HTML context. 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! I disagree; it's no more clear to end users. There is no reason the status bar at the bottom couldn't say http://example.com/report (PDF Document) Trivial addition for browsers to take this information from the Accept attribute. Not quite trivial, since browsers to do what you ask would need to maintain a table of pretty names for all MIME types - including translating that table to all languages the UI is translated to... They could support the most common, the rest could be output http://example.com/report (application/foo). This problem is no better addressed using a URL. On a more serious note: content negotiation is meant to automatically choose a variant of a resource (format, language). However, in many cases the variant is significant in a way that I as a user want control over. 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. The same document provided in different formats is one resource and multiple representations. Representations are distinct from resources and therefore don't fit into the definition of Uniform Resource Locator. I've built two-three websites that use content/language negotiation and I now consider it an architectural mistake to rely on negotiation because the URLs no longer uniquely identify the variants I in many scenarios need to identify. It's OK-ish to do it as a pure format choice where the server and UA just agree on using the PNG or GIF version for an IMG tag. 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. Because: 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. This kind of behavior *breaks caching*, for obvious reasons. As a URL user (web browsing human, HTML author, linker, bookmarker, E-mail-with-links author) I often want to be sure about what variant of a resource I link to. To be explicit about this across scenarios requires explicit URLs with language and type information. If you put .pdf at the end a URL the server wont necessarily respond with a PDF content type, so any extra certainty you feel from that is artificial. 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'? It only exists because of the present insufficiencies of HTML to provide browsers with a way to leverage protocol level conneg. Content negotiation is a lot nicer in theory than in practise.. Well it's not nice in practice because HTML is currently flawed After thinking about it I've concluded that it's not nice in practice because the basic premise of content negotiation is fundamentally flawed, namely that what variant of a resource users get from a URL is insignificant and what's best for them can be determined automatically. Automatically is the case for user agents that interpret specific content types; i.e. pdf readers would only Accept application/pdf documents. Browsers are a specific type of user agent that are primarily used for reading hypermedia; but also, importantly, Accept many other different content types which
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
On Tue, Nov 18, 2008 at 11:52 AM, Mike [EMAIL PROTECTED] wrote: Thomas Broyer wrote: On Mon, Nov 17, 2008 at 6:31 PM, [EMAIL PROTECTED] wrote: - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. How about other representations? (I know we're discussing HTML here, and not HTTP, but what if a resource has no HTML representation? are you proposing adding this capability to PDF, MSOffice, OpenDocument, et al. too?) That's an issue at the application level; RSS would work fine in that situation - any form of hypermedia will serve that purpose. How would RSS work better than HTML (as of today; i.e. without your proposed extension)? Maybe you could explain how browsers do not conform to HTTP? (and no, HTTP does not mandate user-agents to give the control of the Accept-* headers to the user or the... server?!) URI = Uniform Resource Identifier A given document available in html, pdf, xml - is one resource. The various content types are representations of that resource. That's one way of looking at things, not *the* way (see below). Because HTML is presently insufficient in providing a mechanism for browsers to perform protocol level conneg.. it's been moved into the URI and each representation is provided as a separate resource. This clearly breaks the intended definition of a URI - this is why I don't consider browsers to conform to HTTP; since they force developers to misuse that part of the protocol. If you want to precisely identify the PDF version of that document, you need another resource (whose representations is a set with a single value: PDF). If your URI idenfies this document, you cannot blame anyone but yourself for not being able to identify this document in PDF. Anyway, we're going real far from this WG's scope, so I propose we follow up in private, or, even better, you re-hash the debate on the rest-discuss list or with Roy T. Fielding if you want. Having to use a JavaScript virtual machine to perform PUT and DELETE is yet another example of this. Conforming to HTTP does not mean supporting all of the defined methods (even at the server-side: a server is free to return a 501). There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the servers the ability to describe the available variants of a given resource in a content-type independent way. You'd rather push browser vendors to implement TCN/RSVA than HTML5 to add a content-type dependent equivalent. See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5 I don't really understand the point your making.. I would just like to see a way by which developers can link to *resources* with URIs and specify the representation if and when necessary for a given link. So make another URI to identify that particular resource: the same as X but available only in format Y. There is no choice at the moment because HTML is insufficient. I believe HTML is not in cause here (as any format with hyperlinking feature would be insufficient too: as I said above: PDF, MSOffice, OpenDocument, RSS, Atom, etc.) - I'll say it again: I'm encouraging you to help browsers become better HTTP clients; surely that is high on the agenda here.. right?! No, we're discussing HTML and some Web APIs here, not HTTP. So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper Text are not closely linked? No. HTTP does not need HTML (WebDAV and CalDAV, for instance, do not need HTML to work). and HTML does not need HTTP (aren't you sending HTML mails yourself? and most documentation nowadays is in HTML format stored on disk, without HTTP entering into play). However, HTTP and HTML both make an heavy use of URI/URL. - separate versions are separate resources, not separate content types. That has nothing to do with conneg.. s/version/variant/ Variants still need be produced by someone or something, and there really might be discrepencies between them; that's why there's a quality parameter in TCN/RSVA (and thus in Apache type-map files, for instance) I'm not sure what you're getting at here. Multiple versions are multiple resources, they aren't seperate types so conneg is not appropriate. URIs handle this, the example I gave (which you left out) is proof of that. Let me try again: your document is available in HTML and PDF (let's keep it simple). Who makes the HTML? Who makes the PDF? How can you be 100%-sure that both variants are strictly identical (if ever they can)? Let's consider the famous SVG tiger image, that you would make available in both SVG and PNG. Isn't the SVG qualitatively better than the PNG? Aren't they the same resource sketch of a tiger? How about an interactive animation you provide in both SVG+JS and Flash. What if there's a bug the SVG variant (e.g. because of cross-UA incompatibility)? They're the same resource, yet there can be discrepencies between the two variants
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
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/pdfreport/a the server could respond with an executable too. This argument is perfectly irrelevant to your case for HTTP-related attributes. I
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Mike wrote: The benefits? Oh I don't know.. a markup language that supports the transfer protocol it runs on?! Who says you have to serve HTML over HTTP? I see it served via email (and newsgroups), local filesystems, and FTP on a regular basis. Indeed, making HTML depend on HTTP-specific features sounds like A Bad Idea™ (and if you retort XMLHTTPRequest, let me point out that I personally would have objected to injecting HTTP specifics into that interface, had I been around during the design phases). To follow your arguments to the logical conclusion, HTML would have to have special attributes to deal with circumstances within email messages, specific attributes to handle certain filesystem-specific abilities, or quirks of the FTP protocol. I think you'll find such a position untenable; ask yourself then, why limit it to HTTP? -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Joshua Cranmer wrote: Mike wrote: The benefits? Oh I don't know.. a markup language that supports the transfer protocol it runs on?! Who says you have to serve HTML over HTTP? I see it served via email (and newsgroups), local filesystems, and FTP on a regular basis. Indeed, making HTML depend on HTTP-specific features sounds like A Bad Idea™ (and if you retort XMLHTTPRequest, let me point out that I personally would have objected to injecting HTTP specifics into that interface, had I been around during the design phases). To follow your arguments to the logical conclusion, HTML would have to have special attributes to deal with circumstances within email messages, specific attributes to handle certain filesystem-specific abilities, or quirks of the FTP protocol. I think you'll find such a position untenable; ask yourself then, why limit it to HTTP? I wouldn't limit it to that, but I don't have the time or inclination to investigate other applicable protocols that suffer equally poor support in HTML. If you can evidence this the same way I have for Accept headers in HTTP; let me know - I'll champion that too if it makes you feel better! :) Regards, Mike
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
On 18 Nov 2008, at 16:41, Joshua Cranmer wrote: (and if you retort XMLHTTPRequest, let me point out that I personally would have objected to injecting HTTP specifics into that interface, had I been around during the design phases) XMLHttpRequest doesn't need to be XML, it doesn't need to be HTTP (FTP should work fine too in browsers IIRC), so all it really is is a generic request object. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
On 17/11/2008 11:29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone else agree that an Accept attribute would be a useful tool for making browser interaction more RESTful? Is it worth persuing this issue with the HTML5 working group? I don't see why the Accept header when following links or requesting images should be controlled by anything other than the browser. It's the browser that has to decide actually render the returned content so it's in the best position to decide what it can accept, not the page author. On the other hand, XMLHttpRequest should be able to control the Accept header because the page author will control the JavaScript which has to handle the response. I would have thought this was already possible though. Is there a particular use case you had in mind where the HTML author would know what the browser accepts better than the browser does? Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Adrian, The server is not obliged to respect the Accept header, there is nothing preventing the server from returning a gif even if the Accept header indicates solely png. This is actually the case with specifying content type in the URL, since there is nothing preventing example.com/index.html returning a jpeg for example. A URI is a resource identifier - content-type is seperate from that, and concerned with a specific representation of a resource rather than the resource itself. This was the intention of the Accept header being included in the HTTP protocol, as per my understanding from the rfc and Roy Fielding's thesis. From my perspective, it seems wasteful to ignore this opportunity to expand the ability of the markup to better reflect best-practice HTTP transactions by including an optional header. Surely it is better if HTML and browsers can support this natively without having to resort to javascript hackery. as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. A browser is a special case in which many different content-types are dealt with. The same benefit is not achieved if the content is negotiated via the URL, since the user would have to know the type their user agent required and modify the URL accordingly: example.com/report?type=application/rss+xml To me, this is a much cleaner and more appropriate use of a URI. Not to mention more user-friendly. Something, I believe should be encouraged - this is why I feel it would be an important addition to HTML5. Any thoughts? Regards, Mike On 17/11/2008 11:29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone else agree that an Accept attribute would be a useful tool for making browser interaction more RESTful? Is it worth persuing this issue with the HTML5 working group? I don't see why the Accept header when following links or requesting images should be controlled by anything other than the browser. It's the browser that has to decide actually render the returned content so it's in the best position to decide what it can accept, not the page author. On the other hand, XMLHttpRequest should be able to control the Accept header because the page author will control the JavaScript which has to handle the response. I would have thought this was already possible though. Is there a particular use case you had in mind where the HTML author would know what the browser accepts better than the browser does? Regards, Adrian Sutton.
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Just to clarify - I was suggesting that the type-less URI and Accept header method was a better solution, not the example.com/report?type=application/rss+xml example I gave. Also; including an optional header should be including an optional attribute. Sorry for any confusion! Regards, Mike --- Adrian, The server is not obliged to respect the Accept header, there is nothing preventing the server from returning a gif even if the Accept header indicates solely png. This is actually the case with specifying content type in the URL, since there is nothing preventing example.com/index.html returning a jpeg for example. A URI is a resource identifier - content-type is seperate from that, and concerned with a specific representation of a resource rather than the resource itself. This was the intention of the Accept header being included in the HTTP protocol, as per my understanding from the rfc and Roy Fielding's thesis. From my perspective, it seems wasteful to ignore this opportunity to expand the ability of the markup to better reflect best-practice HTTP transactions by including an optional header. Surely it is better if HTML and browsers can support this natively without having to resort to javascript hackery. as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. A browser is a special case in which many different content-types are dealt with. The same benefit is not achieved if the content is negotiated via the URL, since the user would have to know the type their user agent required and modify the URL accordingly: example.com/report?type=application/rss+xml To me, this is a much cleaner and more appropriate use of a URI. Not to mention more user-friendly. Something, I believe should be encouraged - this is why I feel it would be an important addition to HTML5. Any thoughts? Regards, Mike On 17/11/2008 11:29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone else agree that an Accept attribute would be a useful tool for making browser interaction more RESTful? Is it worth persuing this issue with the HTML5 working group? I don't see why the Accept header when following links or requesting images should be controlled by anything other than the browser. It's the browser that has to decide actually render the returned content so it's in the best position to decide what it can accept, not the page author. On the other hand, XMLHttpRequest should be able to control the Accept header because the page author will control the JavaScript which has to handle the response. I would have thought this was already possible though. Is there a particular use case you had in mind where the HTML author would know what the browser accepts better than the browser does? Regards, Adrian Sutton.
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hey Mike, Good answers. :) The server is not obliged to respect the Accept header, there is nothing preventing the server from returning a gif even if the Accept header indicates solely png. This is actually the case with specifying content type in the URL, since there is nothing preventing example.com/index.html returning a jpeg for example. Agreed. A URI is a resource identifier - content-type is seperate from that, and concerned with a specific representation of a resource rather than the resource itself. This was the intention of the Accept header being included in the HTTP protocol, as per my understanding from the rfc and Roy Fielding's thesis. Agreed. as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a Ok, this is an interesting example. Quite a few sites have a PDF Version link which could be better done by linking to the same URL with different accept headers - though you'd obviously have to set the Vary cache control header appropriately. So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. A browser is a special case in which many different content-types are dealt with. The same benefit is not achieved if the content is negotiated via the URL, since the user would have to know the type their user agent required and modify the URL accordingly: example.com/report?type=application/rss+xml This seems like a different use case to me and should be possible without any additional modifications. If the server is configured to return PDF if that's the first thing in the Accept header *and* the user pastes the URL into Acrobat instead of their browser, Acrobat would obviously prefer PDF so list that first and have that returned by the server. Note though, that in this case the user agent is responsible for setting the Accept header so we don't need to change the HTML spec at all. The reason this is basically never used today is two fold: 1. It requires correctly configuring the server, beyond just putting files on the file system. Very few people actually do this. 2. It requires the user to see a URL and decide that they want to paste it into Acrobat instead of their browser, without any indication that it would actually work. To me, this is a much cleaner and more appropriate use of a URI. Not to mention more user-friendly. Something, I believe should be encouraged - this is why I feel it would be an important addition to HTML5. I agree this is pretty cool, but I don't see it every gaining traction, because it requires so much more effort to set up than just having report.html and report.pdf and report.xml which work correctly with the server and caches out of the box. The fact that users are so unlikely to put the URL into anything but a browser just makes it even less likely that this effort would be rewarded. Incidentally, a report.pdf in the URL would dramatically increase the chances of the user trying to load it directly in Acrobat instead of their browser because they can see that it's going to be a PDF. It is a cool idea though... Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
[EMAIL PROTECTED] writes: as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a So I can send a colleague a message; 'you can get the report at http://example.com/report', and they can use that URL in any user agent that is appropriate. Except that in practice on receiving a URL like the above, nearly all users will try it in a web browser; they are unlikely to put it into their PDF viewer, in the hope that a PDF version of the report will happen to be available. A browser is a special case in which many different content-types are dealt with. It's also the most common case. Supposing I opened the above URL in a browser, and it gave me the HTML version; how would I even know that the PDF version exists? Suppose my browser has a PDF plug-in so can render either the HTML or PDF versions, it's harder to bookmark a particular version because the URL is no longer sufficient to identify precisely what I was viewing. Browsers could update the way bookmarks work to deal with this, but any exterrnal (such as web-based) bookmarking tools would also need to change. Or suppose the HTML version links to the PDF version. I wish to download the PDF on a remote server, and happen to have an SSH session open to it. So I right-click on the link in the HTML version I'm looking at, choose 'Copy Link Location' from the menu, and in the remote shell type wget then paste in the copied link. If the link explicitly has ?type=PDF in the URL, I get what I want; if the format is specified out of the URL then I've just downloaded the wrong thing. Smylers
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Except that in practice on receiving a URL like the above, nearly all users will try it in a web browser; they are unlikely to put it into their PDF viewer, in the hope that a PDF version of the report will happen to be available. I've adressed this subsequently: 'here's the URL: example.com/report you can open this with adobe, excel, powerpoint, word' It's also the most common case. Supposing I opened the above URL in a browser, and it gave me the HTML version; how would I even know that the PDF version exists? Hypertext. Suppose my browser has a PDF plug-in so can render either the HTML or PDF versions, it's harder to bookmark a particular version because the URL is no longer sufficient to identify precisely what I was viewing. Browsers could update the way bookmarks work to deal with this, but any exterrnal (such as web-based) bookmarking tools would also need to change. I've also already addressed this in the original post; I was quite clear that if browsers don't store the application state when you make a bookmark (headers, URI, HTTP method), then this is an argument for continuing to use URI conneg *aswell* as HTTP conneg; rather than instead. Until the browsers fix this. ;) Browsers should really be bookmarking the whole request/state; the only reason they don't do this is because that's not the way it's done now. The reason for that is lack of incentive due to inadequate tooling, it's not a fair justification to say 'no one does it at the moment because its not necessary', that's disingenuous. The real reason is that HTTP is not adequately supported in HTML, and so browser requests never contain appropriately descriptive headers - hence why conneg was forced into the URI. Alot of people, including the guys in the IRC channel, seem to be blaming the insufficiencies of HTTP conneg on HTTP itself. Please feel free to describe these inherent problems with HTTP conneg without implying browsers and HTML don't do it properly. I know they don't..! I don't consider that a criticism of HTTP, for obvious reasons. Or suppose the HTML version links to the PDF version. I wish to download the PDF on a remote server, and happen to have an SSH session open to it. So I right-click on the link in the HTML version I'm looking at, choose 'Copy Link Location' from the menu, and in the remote shell type wget then paste in the copied link. If the link explicitly has ?type=PDF in the URL, I get what I want; if the format is specified out of the URL then I've just downloaded the wrong thing. Here you go: wget example.com/report --header=Accept: application/pdf Regards, Mike
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
[EMAIL PROTECTED] writes: It's also the most common case. Supposing I opened the above URL in a browser, and it gave me the HTML version; how would I even know that the PDF version exists? Hypertext. OK. Except that in practice on receiving a URL like the above, nearly all users will try it in a web browser; they are unlikely to put it into their PDF viewer, in the hope that a PDF version of the report will happen to be available. I've adressed this subsequently: 'here's the URL: example.com/report you can open this with adobe, excel, powerpoint, word' Would the sender of that link necessarily know all the formats the URL provides? Anyway, that's an unrealistic amount of typing -- typically round here people just copy and paste a URL into an instant message and send it without any surrounding text. Whereas without any other information, people will generally open URLs in a web browser. So it'd be faster just to send the URL of the page which contains hypertext links to all the formats; at which point we no longer care whether those links specify the format in the URL or elsewhere. Suppose my browser has a PDF plug-in so can render either the HTML or PDF versions, it's harder to bookmark a particular version because the URL is no longer sufficient to identify precisely what I was viewing. Browsers could update the way bookmarks work to deal with this, but any exterrnal (such as web-based) bookmarking tools would also need to change. I've also already addressed this in the original post; I was quite clear that if browsers don't store the application state when you make a bookmark (headers, URI, HTTP method), then this is an argument for continuing to use URI conneg *aswell* as HTTP conneg; rather than instead. What is the point of doing it in HTTP if it's being done in HTML anyway? Until the browsers fix this. ;) Not just browsers, as I pointed out. Also many databases which have tables with URL fields would need extra fields adding. Browsers should really be bookmarking the whole request/state; the only reason they don't do this is because that's not the way it's done now. The reason for that is lack of incentive due to inadequate tooling, it's not a fair justification to say 'no one does it at the moment because its not necessary', that's disingenuous. True. But if the current way of doing it is good enough, there's no incentive to change. There's little point in making browsers implement extra functionality and inventing new mark-up and evangelizing it, only to end up with the same functionality we started with; there has to be more. And the greater the effort involved, the greater the benefit has to be to make it worthwhile. Or suppose the HTML version links to the PDF version. I wish to download the PDF on a remote server, and happen to have an SSH session open to it. So I right-click on the link in the HTML version I'm looking at, choose 'Copy Link Location' from the menu, and in the remote shell type wget then paste in the copied link. If the link explicitly has ?type=PDF in the URL, I get what I want; if the format is specified out of the URL then I've just downloaded the wrong thing. Here you go: wget example.com/report --header=Accept: application/pdf Typing that would require my knowing that URL of the PDF also serves other formats. But, moreover, it requires typing. Currently the URL can be pasted in, the text that the browser copied to the clipboard. There's no way that my browser's 'Copy Link URL' function is going to put on the clipboard the exact syntax of wget command-line options. Having to type that lot in massively increases the effort in this task -- even if I can type the relevant media type in from the top of my head, without needing to look it up. Or what about if I wanted to mail somebody pointing out a discrepency between two versions of the report, and wished to link to both of them. That's tricky if they have the same URL. Possibly I could do it like you have with the wget command-line above, but that requires me knowing which browsers my audience use and the precise syntax for them. Smylers
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Would the sender of that link necessarily know all the formats the URL provides? Anyway, that's an unrealistic amount of typing -- typically round here people just copy and paste a URL into an instant message and send it without any surrounding text. Whereas without any other information, people will generally open URLs in a web browser. So it'd be faster just to send the URL of the page which contains hypertext links to all the formats; at which point we no longer care whether those links specify the format in the URL or elsewhere. - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. What is the point of doing it in HTTP if it's being done in HTML anyway? - Nothing is 'done' in HTML, it's a markup language. It's being done (at the moment) in the URI. HTTP provides conneg, why would you consciously deny developers the opportunity to use it in browsers? Unless HTML5 provides the markup, this isn't possible. This means Browsers don't have the ability to fully support HTTP without having to use JavaScript rubbish; there is a window of opportunity to change this with HTML5. Not just browsers, as I pointed out. Also many databases which have tables with URL fields would need extra fields adding. - I suggested the attribute should be optional, so it would make no difference; one would simply avoid using it if it was a big problem. True. But if the current way of doing it is good enough, there's no incentive to change. - Define 'enough'..! I don't know why/how you get the authority to make that assumption! And before you say it; I'm not assuming any authority myself - I'm trying to encourage you to help browsers conform to the protocol they make use of. There's little point in making browsers implement extra functionality and inventing new mark-up and evangelizing it, only to end up with the same functionality we started with; there has to be more. And the greater the effort involved, the greater the benefit has to be to make it worthwhile. - I'll say it again: I'm encouraging you to help browsers become better HTTP clients; surely that is high on the agenda here.. right?! Typing that would require my knowing that URL of the PDF also serves other formats. But, moreover, it requires typing. Currently the URL can be pasted in, the text that the browser copied to the clipboard. There's no way that my browser's 'Copy Link URL' function is going to put on the clipboard the exact syntax of wget command-line options. Having to type that lot in massively increases the effort in this task -- even if I can type the relevant media type in from the top of my head, without needing to look it up. - You're using a command line and complaining about having to type too much? If it mattered that much it would be a 2 second job to write a wrapper script of some kind.. wget is a developer tool it's not supposed to be convenient anyway. Or what about if I wanted to mail somebody pointing out a discrepency between two versions of the report, and wished to link to both of them. That's tricky if they have the same URL. Possibly I could do it like you have with the wget command-line above, but that requires me knowing which browsers my audience use and the precise syntax for them. - separate versions are separate resources, not separate content types. That has nothing to do with conneg.. if you wanted my take on it I'd do it like this: example.com/report (automatically provides latest report) example.com/report/versions (list all versions) example.com/report/versions/0.1 (version 0.1) example.com/report/versions/5.6 (version 5.6) obviously I'd make each of those available as json, xml, html, pdf, xls, and whatever else worked! :) Regards, Mike
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
[EMAIL PROTECTED] schrieb: [...] Please quote properly. Otherwise it's incredibly hard to follow the discussion. Thanks. Philipp Kempgen
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hallvord R M Steen wrote: as an example: a href=http://example.com/report;html report/a a href=http://example.com/report; Accept=application/pdfpdf report/a a href=http://example.com/report; Accept=application/rss+xmlxml report/a Sorry, both as an author and as a user I'd prefer this: a href=http://example.com/report;html report/a a href=http://example.com/report.pdf;pdf report/a a href=http://example.com/report.xhtml;xml report/a - Keep It Simple. For me as an author it's less typing, and for me as a computer-literate end user it's clear whether a link is going to make me wait for Acrobat loading or open directly - even if the link is taken out of the HTML context. It's less typing - Is that serious or are you joking?! I disagree; it's no more clear to end users. There is no reason the status bar at the bottom couldn't say http://example.com/report (PDF Document) Trivial addition for browsers to take this information from the Accept attribute. If you put .pdf at the end a URL the server wont necessarily respond with a PDF content type, so any extra certainty you feel from that is artificial. It should be up for interpretation whether you chose to do it this way or not. At the moment HTML is not providing a way to take advantage of HTTP conneg, that's not very fair - particularly given the criticism that 'its not possible at the moment'. Surely a primary objective here must be allowing browser developers to make full use of every aspect of the HTTP protocol? On the other hand, I'd sort of like a href=http://example.com/report; AcceptLanguage=noNorwegian/a a href=http://example.com/report; AcceptLanguage=enEnglish/a As the main problem with using content-negotiation for language right now is that you need to hard-link to actual files (i.e. file.en.html) to give users a way to override the negotiation on the fly. (No, nobody will reconfigure their browser to use your site and everyone must be given a choice of language even if they can't control the settings of the browser they happen to use.) It's not good enough though, since one would like the language choice to stick automatically - you still need to fall back to cookies and a custom script for handling language choice or no suitable version errors. Content negotiation is a lot nicer in theory than in practise.. Well it's not nice in practice because HTML is currently flawed and insufficient as a way of telling browsers how to do it properly. This is entirely my point; let's make HTTP conneg possible in browsers by getting HTML right - and let the developers decide the best practices. By not supporting this part of the HTTP protocol (content negotiation) you are taking something fundamental out of the hands of application developers (client and server side) because you don't think it's necessary. The apparent resistance to this confuses me; since the solution is not complicated to implement, completely backwards compatible, and ignorable. Regards, Mike
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
[EMAIL PROTECTED] writes: Would the sender of that link necessarily know all the formats the URL provides? Anyway, that's an unrealistic amount of typing -- typically round here people just copy and paste a URL into an instant message and send it without any surrounding text. Whereas without any other information, people will generally open URLs in a web browser. So it'd be faster just to send the URL of the page which contains hypertext links to all the formats; at which point we no longer care whether those links specify the format in the URL or elsewhere. - The HTML version of that URL could provide the web page representation *and* provide links to all the other content types available. Indeed it could. In which case the original claimed advantage of the recipient of the message being able to open a single URL in one of several different sorts of user-agents is no longer relevant; the links could specify the format in the URL and this'll work just fine. What is the point of doing it in HTTP if it's being done in HTML anyway? - Nothing is 'done' in HTML, it's a markup language. It's being done (at the moment) in the URI. Sorry; that was what I meant. HTTP provides conneg, why would you consciously deny developers the opportunity to use it in browsers? HTML 5 implicitly denies things merely by not providing them. And it provides things which are useful. So the question actually needs to be asked the other way round: what benefits are there in this being supported? Not just browsers, as I pointed out. Also many databases which have tables with URL fields would need extra fields adding. - I suggested the attribute should be optional, so it would make no difference; one would simply avoid using it if it was a big problem. If my database contains URLs of external websites, then it isn't under my control as to whether this feature gets used. If those sites start using it, then my URLs are no longer sufficient to uniquely identify what is downloaded, and I need to change my database schema (and software that uses it) to remedy that. True. But if the current way of doing it is good enough, there's no incentive to change. - Define 'enough'..! I don't know why/how you get the authority to make that assumption! I don't, of course! But then, I never made that claim anyway; I said _if_ it's good enough. That is, in order to make this change let's first show that the current way isn't good enough. And before you say it; I'm not assuming any authority myself Good; the editor has a policy of ignoring appeals to authority! There's little point in making browsers implement extra functionality and inventing new mark-up and evangelizing it, only to end up with the same functionality we started with; there has to be more. And the greater the effort involved, the greater the benefit has to be to make it worthwhile. - I'll say it again: I'm encouraging you to help browsers become better HTTP clients; surely that is high on the agenda here.. right?! Why? That's tantamount to an appeal to authority. Fully supporting HTTP is a means rather than an end. Are there situations in which supporting this particular part of HTTP provides additional benefit to users? Or are there many instances of authors tediously coding the same thing in JavaScript? Changes should have some real-world benefit, not just bureaucratically complying with something for the sake of it. Typing that would require my knowing that URL of the PDF also serves other formats. But, moreover, it requires typing. Currently the URL can be pasted in, the text that the browser copied to the clipboard. There's no way that my browser's 'Copy Link URL' function is going to put on the clipboard the exact syntax of wget command-line options. Having to type that lot in massively increases the effort in this task -- even if I can type the relevant media type in from the top of my head, without needing to look it up. - You're using a command line and complaining about having to type too much? Yes. One reason I find using the command line so efficient is that there are many features and short-cuts for avoiding having to type things fully. If it mattered that much it would be a 2 second job to write a wrapper script of some kind.. That does what? A wrapper script which somehow contacts my web browser (running on a different computer) to find out what the media type is of the link that was most recently copied to the clipboard? Even if I could work out how to write such a script, why should I have to? wget is a developer tool Is it? I thought it was a program for downloading files from the web. it's not supposed to be convenient anyway. Isn't it? I find it most convenient. One of the reasons I use it is because its interface is so simple: just change to the directory I wish to download something to (which is effectively free, since once the download has finished I'll
