- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Wed, 29 Apr 2015 21:48:19 +0200
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>, 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 2015-04-29 20:00, henry.story@bblfish.net wrote: > >> 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: There are constraints on header field sizes as well. So this may work a *bit* better than URI parameters, but it will hit some limit as well. The result will need to vary on "Query", so it won't be cached a lot. Also don't forget to think about non-ASCII characters in the header field. > 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 Or you could use SEARCH :-) Best regards, Julian
Received on Wednesday, 29 April 2015 19:48:44 UTC