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

On Mon, Aug 15, 2005 at 08:59:11 -0400, Kendall Clark wrote:
> > Also, I dont see an explanation of how do deal with other protocol level
> > faults (eg. client sends Accept: application/my-wacky-rdf-syntax), I guess
> > we fall back to sensible HTTP responses, but this could be made explict if
> > its the case. How does it apply to SOAP?
> 
> 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. It wasn't clear to me if that was legal or
not. I guess it would have been if I digested all of WSDL2, that that aint
going to happen today :)
 
> > The response code is "400 Bad Request", and the WSDL contains some
> > references to 400, but its not in the text. I would prefer it if the
> > response codes were specified in human-speak too, in section 4. Ditto for
> > the 500 in the next example.
> 
> That's part of the HTTP bindings description I've yet to finish writing.

OK, I didn't see @@s or red on that subject.
 
> > I'm not clear on whether its allowed for the server to return more specific
> > errors where applicable, eg 413 Request Entity Too Large could be
> > appropriate in some cases.
> 
> Yes, I thought long and hard about this issue, finally deciding to return
> the most generic 4 & 5 faults. I think there's language in the HTTP spec
> about returning more specific ones, but I can't recall.
> 
> I'm pretty sure we could analogize lots of different HTTP faults to
> different SPARQL cases, but I've tried to be minimalist. I guess I'd need to
> hear more discussion or use cases for adding more faults.
> 
> (Though, in the case of 413, I may put some language in the spec about
> returning it iff a service doesn't implement the query1 operation, that is,
> the POST binding. That reinforces the idea that GET is to be preferred,
> generally, to POST, except in cases of very large queries.)
> 
> > "j. SELECT with query request refused fault", I'm not convinced that
> > 500 is the most appropraite error. I can see the case for 403 Forbidden,
> > though its is also not neccesarily a perfect fit. From
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> > "403 Forbidden. The server understood the request, but is refusing to
> > fulfill it. Authorization will not help and the request SHOULD NOT be
> > repeated. If the request method was not HEAD and the server wishes to make
> > public why the request has not been fulfilled, it SHOULD describe the
> > reason for the refusal in the entity."
> 
> 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. Its not a server fault per se, its made the decision not to execute
the query. I can see both sides though.
 
> > "3. Policy Considerations", should also mention that the
> > default-graph-uri etc. parameters can cause multiple HTTP requests to be
> > issued in response to a single query request. 
> 
> It does mention that:
> 
>   Another possible source [of DOS attacks] are queries containing very
>   complex -- either because of resource size, the number of resources to be
>   retrieved, or a combination of size and number -- RDF dataset
>   descriptions, 
> 
> Is that insufficient?

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.
 
> > This could make the SPARQL
> > protocol a vector for denial of service attacks - it both anonymises the
> > originator of the requests, and escalates the number of requests for a
> > small request cost. Needs some similar text to the direct DOS comments.
> 
> I don't get the part about similar text...

In the last paragraph we have:

"SPARQL query processing services may choose to detect these and other
costly queries, impose time or memory limits on queries, or impose other
restrictions to reduce the service's vulnerability to denial-of-service
attacks. They also may refuse to process such query requests."

It just needs to be a bit more general I think.
 
> > General comment. I'm not a fan of the sytle of incuding only the
> > most-specific subsection identifier. It make it hard to refer to sections.
> > Is this just for editing purposes? Minor issue.
> 
> Instead of a less-specific identifier? Not sure how that's better.

I mean "i title" -> "H.3.i title" or similar, but its not a big deal, just
personal preference.
 
> > How should HEAD requests be handled? This might be implicit in the WSDL,
> > but I'd like a line or two in the text.
> 
> What about HEAD requests? There's no operation in the abstract protocol that
> binds to HEAD requests. Can you say more about this?

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

My pleasure.

- Steve

Received on Monday, 15 August 2005 13:47:54 UTC