Re: URI serialization issues

On Jan 17, 2006, at 4:16 PM, Kendall Clark wrote:

>
> On Jan 17, 2006, at 11:34 AM, Mark Baker wrote:
>
> Actually, Mark, I just realized that the editor's draft already has  
> language to this effect:
>
> <p>The <code>queryHttpGet</code> binding <strong>should</strong> be  
> used except in cases where the URL-encoded query exceeds  
> practicable limits, in which case the <code>queryHttpPost</code>  
> binding <strong>should</strong> be used.</p>

Er, scratch that bit, as I just realized I quoted back to you what  
you quoted to me (the up-case SHOULDs threw me off for a bit)...

> Is that sufficient? (Now that I've thought about things a bit more,  
> the 2nd point seems much more ambiguous and complex.)

I now realize it's the 2nd point that's the substance of yr  
suggestion. Hmm, I'm more unsure here. A few things:

1. GET being 'safe' is always talked about it terms of side effects  
like deleting a resource -- the DOS issue is different.

2. How does the query coming in via POST instead of GET really help  
anything? In both cases a service may send QueryRequestRefused in  
response to a request that's too expensive to complete. (I'm cc'ing  
Pat Hayes because he +1'd yr comments and I wanna make sure I know  
what he thinks of this.)

3. It's not clear that you can say, statically, in advance, which  
queries against which datasets will be computationally too expensive,  
not least because "cost" may have a load or busyness factor that's  
dynamic. What is my implementation just wants to set a timeout... if  
a query takes longer than 60 seconds, it's too expensive ande I  
return QueryRequestRefused. That seems perfectly reasonable. But in  
that case I may not be doing any query analysis, and so I don't know  
which queries should be POST and which GET. *Confusing* and I don't  
see the utility.

So if there's a request that times out over GET, and I had some way  
(how?) to tell the client to submit again via POST, what would be the  
point of that? It will still timeout via POST and I've only wasted  
the client's time and the service's.

Cheers,
Kendall

Received on Tuesday, 17 January 2006 21:24:23 UTC