W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

Re: Review of http://www.w3.org/2001/sw/DataAccess/proto-wd/

From: Kendall Clark <kendall@monkeyfist.com>
Date: Mon, 15 Aug 2005 10:07:07 -0400
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20050815140707.GD27574@monkeyfist.com>

On Mon, Aug 15, 2005 at 02:46:39PM +0100, Steve Harris wrote:

> > Yeah, I'm not sure we need to re-document HTTP stuff. In fact, I've had
> > feedback that we should *not* do so, as in the case of con-neg. Not sure
> > what to do about this, frankly. Advice welcomed.
> 
> I dont know about the WSDL mechanics, but a line like "for other fault
> conditions use HTTP error responses as appropriate [ref]" would have done
> fine - if thats the intention. 

But we're only documenting two fault conditions, MalformedQuery and
QueryRequestRefused, so I'm not sure what it would mean to say "other fault
conditions" specific to SPARQL Protocol. There are, of course, other
conditions, but I think if we care enough to say that you can "just use HTTP
for them", then we should define them in the spec.

> > Well, I think it should be a 5xx status code because it's the server that's
> > refusing the request, for *whatever reason*, and that doesn't mean it's
> > necessarily a client fault. In fact, it's probably not. It should be, IMO,
> > one of the 5xx faults.
> 
> True, but equally its refusing it because of something the client has
> done. 

But not something that the client has done that's a *fault* or error, right?
The client asking the server to retrieve the World's Largest RDF Graph and
do a very complex query upon it is perfectly legal, it's just not sane. :>

I do think this is a bit of coin toss, and now we've at least discussed it
some.

> Its not a server fault per se, its made the decision not to execute
> the query. I can see both sides though.

Okay.

> I think so. The sigficant point is that the protocol is acting as a vector
> for attacks, and its the fact that one request can trigger multiple
> requests that makes it especially problematic.
> 
> Its not a DOS on the sparql service thats neccesarily the issue, its
> using the sparql service to attack other services.

Ah, very well, I'll talk about that, then. Good point.

> It just needs to be a bit more general I think.

I added some text and tweaked some other bits in the Policy section in
response to this feedback. Thanks, Steve.

> I mean "i title" -> "H.3.i title" or similar, but its not a big deal, just
> personal preference.

Oh, sure, I'll try to fix those up.

> I just wondered whats suposed to happen if you present a sparql service
> with a HEAD request (ditto PUT, META or whatever).

That's undefined intentionally in the present design. Previous versions of
the protocol design did interesting (in the opinions of some, anyway) with
other HTTP methods, but those versions failed to gain much support. Alas. :>

Kendall
Received on Monday, 15 August 2005 14:07:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT