- From: John Kemp <john@jkemp.net>
- Date: Wed, 19 Aug 2009 13:50:52 -0400
- To: Jamie Lokier <jamie@shareable.org>
- CC: noah_mendelsohn@us.ibm.com, 'David Booth' <david@dbooth.org>, Kristof Zelechovski <giecrilj@stegny.2a.pl>, hybi@ietf.org, 'Ian Hickson' <ian@hixie.ch>, uri@w3.org, uri-request@w3.org, uri-review@ietf.org
Jamie Lokier wrote: > noah_mendelsohn@us.ibm.com wrote: >> Jamie Lokier writes: ... > Given a URI, you > cannot tell from Content-Type whether that URI supports WebDAV, However, the WebDAV specification does specifically offer some level of compatibility with existing non-WebDAV-aware clients - http://tools.ietf.org/html/rfc4918#appendix-B Without a WebDAV-aware client, I can still perform some non-WebDAV HTTP requests. With a WebDAV-aware client, I can perform WebDAV HTTP requests which the server may or may not support, but the server can tell me, according to HTTP specification that a "method is not supported". > and > you cannot tell whether that URI accepts POSTs to submit new blog > entries - just to pick two widely used examples. A client able to submit a POST can try, but might fail. > > That requires another level of descriptive metadata, which > Content-Type does not provide and is not always available in any other > form. But, just like people can enter a "blog posting" URI into their > mobile phone, there will be reasons why people enter WebSockets URIs > into applications, with no way for the application to verify the > protocol except by trying it. The question is perhaps really about whether you want to provide _some_ compatibility with existing non-websock-aware clients. > >> So, this is a desirable characteristic for Web resources, and it's >> one of the things that HTTP gives you. Indeed, the whole Web is >> designed so that you can start with RFC 3986, the specification for >> URIs, and using the references to which it (recursively) delegates, >> discover how to correctly interact with and interpret responses from >> any resource on the Web. Under the auspices of the W3C TAG, I >> prepared a "finding" [1] that goes into more detail on these issues >> and their implications. > > In other words, I disagree with the above. You can't find which > particular protocols are overlaid on top of HTTP at every findable URI > by the existing mechanisms, and it's unlikely that will ever be > possible. It is possible for those designing Web protocols to consider compatibility with existing Web client software, and to provide ways of allowing new and existing clients to determine the capabilities of HTTP-identified resources. The TAG finding that Noah mentions describes ways in which (some) others have allowed for clients to "follow their noses" and discover how to operate with servers regarding particular resources. There are other ways to do it, but the point is that it depends on protocol designers making the decision to offer such facilities. Using HTTP URIs to identify resources is a good way to begin that process. Regards, - johnk [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
Received on Wednesday, 19 August 2009 17:51:38 UTC