- From: <henry.story@bblfish.net>
- Date: Wed, 29 Apr 2015 20:00:58 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, Michael Sweet <msweet@apple.com>, Eric Covener <covener@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 29 Apr 2015, at 19:12, Zhong Yu <zhong.j.yu@gmail.com> wrote: > > On Wed, Apr 29, 2015 at 11:53 AM, henry.story@bblfish.net > <henry.story@bblfish.net> wrote: > >> But hey if you and everybody else here thinks that deployment is the only >> issue left here, then that would be good to know. :-) > > It appears to me that the only problem SEARCH solves(or rather, > avoids) is the limitation of URI length. That *is* a deployment issue. > > So GET is fine, it's just constrained by the current deployments for > your use cases. You want a workaround, which, nevertheless, works > through *the current deployment*. Ok, we do have a workaround. Andrei Sambra and Sandro Hawke who are closely with Tim Berners Lee at the Distributed Information Group at MIT, have started working a couple of weeks ago on a proposal for a platform called SoLiD ( Social Linked Data ) with which we can build the disitrubted secure social web. This is described in a very early form in this document https://github.com/linkeddata/SoLiD There they have been playing with moving the query to the headers presumably to avoid the problem discussed here. The query looks like this: GET /data/ HTTP/1.1 Host: example.org Query: SELECT * WHERE { ?s ?p ?o . } and the response looks like this: HTTP/1.1 200 OK { "head": { "vars": [ "s", "p", "o" ] }, "results": { "ordered" : false, "distinct" : false, "bindings" : [ { "s" : { "type": "uri", "value": "https://example.org/data/" }, "p" : { "type": "uri", "value": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" }, "o" : { "type": "uri", "value": "http://www.w3.org/ns/ldp#BasicContainer" } }, { "s" : { "type": "uri", "value": "https://example.org/data/" }, "p" : { "type": "uri", "value": "http://purl.org/dc/terms/title" }, "o" : { "type": "literal", "value": "Basic container" } } ] } } I imagine we could use this as a fall back position to work around issues if they appear. One would need to specify the query mime type too in a header of course. This would limit the query sizes quite dramatically, and does not feel as good as the GET with body. So if we were to specify this in an RFC one could have either a fallback RFC for the intermediate stage, or specify the fallback position in the GET + query in the body RFC. Would that work? Henry Story > > Zhong Yu > bayou.io Social Web Architect http://bblfish.net/
Received on Wednesday, 29 April 2015 18:01:29 UTC