Re: TAP parameter=value issue

Hi Doug!

Yes, I think you're right about url encoding. I refreshed my memory over what it entails. In the past I've only been involved with the receiving end of this stuff. I assume the procedure is to encode each individual parameter value of the request, otherwise you're back to square one. It seems really an implementation issue, so probably one I should not have raised in a standards' debate.

Patrick raised the question of lengths (Thanks, Patrick, for coming to my defence). I've looked on the web and found a number of competing opinions, or possibly implementations (from 255 bytes for early browsers to 32K for CICS!). So I'm really not sure what to think. A couple of thousand seems OK, but who can tell? And encoding will undoubtedly increase the size of a request.

I agree on POST being necessary for asynch requests. But for GET, I'm not too sure about being able to guarantee queries do not change the state of the server. Depends upon what goes into ADQL. Looks like a lot of fun somewhere down the line!

Regards
Jeff

On Fri, 2007-05-18 at 06:36 -0600, Doug Tody wrote:
> Hi Jeff -
>
> Both GET and POST are parameter-based so the encoding issue is
> only partially relevant to the issue under discussion here, which
> was use of data model-based parameter queries in TAP (the point of
> the decision was that TAP should implement only ADQL-based queries,
> as opposed to DM-based constructs like POS,SIZE or RA,DEC,SR).
>
> But anyway, there actually is a standard way to include complex strings
> such as an ADQL expression in a GET, called URL encoding. If an ADQL
> expression gets large enough a POST might eventually be preferable,
> but for 90% of typical simple queries a GET with URL encoding would be
> fine, and is simpler and more RESTful for a synchronous query since
> the query is idempotent. Probably TAP should support both GET and
> POST for synchronous queries, and only POST for asynchronous queries.
> GET is preferred for idempotent (no side affect) references in HTTP
> due to the way the Web is designed, as well as for simplicity.
>
> For information on URL-encoding see for example
>
> http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
>
> We already use URL encoding in VO, for example, one cannot pass an IVOA
> identifier containing the "#" character in a GET unless it is URL encoded.
>
> - Doug

-- 
Jeff Lusted               tel: +44 (0)116 252 5358
Astrogrid Project         mob: +44 (0)7973 492290
Dept Physics & Astronomy  email: jl99-at-star.le.ac.uk
University of Leicester   web: http://www.astrogrid.org