- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 06 Jan 2012 11:23:17 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4F071FF5.40800@openlinksw.com>
On 1/6/12 11:12 AM, Michael Hausenblas wrote: >> My fundamental approach is to understand the rules, but also be >> cognizant of rules violation and the context in which they occur. >> Simply telling folks they broken rules they don't understand or have >> no control over doesn't help end-users, developers, or plumbers >> seeking to exploit the WWW. > > > Agreed. Broken tools should be fixed. Users and developers should be > educated. This is our mission :) I really believe HTTP is worthy of a proper W3C branded training course. Even if the W3C course sources tutors from its membership etc... REST is only comprehensible as style of client-server computing when HTTP is properly understood. Trouble is, we are working with a WWW that (courtesy of marketing driven education) many see as an alternative to client-server (in general). Thus, we've ended up having the ultimate client-server middleware (WWW) being perceived as antithetical to the client-server paradigm :-( Kingsley > > Cheers, > Michael > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 6 Jan 2012, at 15:45, Kingsley Idehen wrote: > >> On 1/6/12 8:48 AM, Michael Hausenblas wrote: >>> >>>> That is a violation of the URI and HTTP specs. >>> >>> >>> And just for the record: this has not/will not change(d) with >>> HTTPbis, see the 'Note' in section. '3.1.1.2. request-target' [1]. >> >> Michael, >> >> Yes, but in the real world wide web, you have parser libraries, >> frameworks etc..., as shown by this simple case that violate this >> rule. The don't process the fragment identifier and you end up with a >> server having to process a URL with a fragment identifier. >> >> A server can 404, 401, 406 etc... and the negotiation conversation >> goes on between user agent and server. >> >> My fundamental approach is to understand the rules, but also be >> cognizant of rules violation and the context in which they occur. >> Simply telling folks they broken rules they don't understand or have >> no control over doesn't help end-users, developers, or plumbers >> seeking to exploit the WWW. >> >> As you know, these kinds of problems dog all standards, so >> implementors do have the option to be more defensive and flexible >> bearing in mind the fundamental goal of reducing hard / >> irrecocoverable faults in the system. Unlike hardcore OS pointers, >> the WWW deftly uses 404 to keep the system rolling :-) >> >> >> Kingsley >> >> >>> >>> Cheers, >>> Michael >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-18#section-3.1.1 >>> >>> -- >>> Dr. Michael Hausenblas, Research Fellow >>> LiDRC - Linked Data Research Centre >>> DERI - Digital Enterprise Research Institute >>> NUIG - National University of Ireland, Galway >>> Ireland, Europe >>> Tel. +353 91 495730 >>> http://linkeddata.deri.ie/ >>> http://sw-app.org/about.html >>> >>> On 6 Jan 2012, at 13:31, Tim Berners-Lee wrote: >>> >>>> >>>> (On 2012-01 -05, at 19:04, Henry Story wrote: >>>> >>>>> 1. do a GET on the URL with #i >>>>> >>>>> --------------------------8<----------------------------8<---------------------------- >>>>> >>>>> hjs@bblfish[0]$ telnet 2sea.org 80 >>>>> Trying 46.228.199.61... >>>>> Connected to 2sea.org. >>>>> Escape character is '^]'. >>>>> GET http://2sea.org/sea.jsp#i HTTP/1.1 >>>> >>>> >>>> That is a violation of the URI and HTTP specs. >>>> Never send the hash over HTTP. >>>> <foo#bar> means "Whatever is referred to a as <#bar> in <foo>". >>>> You must strip off the # and everything after it to retrieve <foo>. >>>> Just don't do it. >>>> >>>> Tim) >>> >>> >>> >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder& CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> >> > > > -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 6 January 2012 16:23:43 UTC