[tdwg-tapir] error in tapir specification?

Wouter Addink wouter at eti.uva.nl
Tue Jul 17 16:30:13 CEST 2007


Hi Renato,
Thanks for your help.
I guess the Tapirlink classes I am working with are a little outdated 
already, but I am using the latest stable release (0.3.1 from April 07). I 
am happy that kvp examples are already working correctly in the newer 
versions, I will also follow the Tapir specs for this then. Will there be a 
new stable release soon? Then I can update my tapirlink classes. I rather 
not work with a development version as there will be pending issues in such 
a version. If QUERY_STRING is part of the CGI spec, I suppose that most 
webservers will supply it. I don't know of servers who don't, but one can't 
test them all... I think restricting content-type in POST requests as you 
suggest would indeed also solve this potential problem.

Wouter

----- Original Message ----- 
From: "Renato De Giovanni" <renato at cria.org.br>
To: <tdwg-tapir at lists.tdwg.org>
Sent: Tuesday, July 17, 2007 3:40 PM
Subject: Re: [tdwg-tapir] error in tapir specification?


> Hi Wouter,
>
> The specification is correct in the KVP examples, but other related
> parts need to be updated. I really hope I can find some time to
> update the specification during the next days. One of the pending
> changes will restrict content-type in POST requests to "application/x-
> www-form-urlencoded" which makes it possible to extract all
> parameters from raw post data when necessary.
>
> You're right that QUERY_STRING should also be available, but isn't
> this variable part of the CGI spec?
> (http://hoohoo.ncsa.uiuc.edu/cgi/env.html)
> I would be interested to know which web servers don't support this
> variable so that I can update TapirLink documentation and warn users
> about the limitation.
>
> A couple of months ago TapirLink was not working with multiple
> concepts in KVP inventory requests, but now it should work (current
> code in Subversion, which should soon be part of a new release).
>
> It's a pity that PHP doesn't handle well multiple parameters with the
> same name without using the square brackets trick. But you can also
> use the code below to get all parameters correctly.
>
> Hope this helps,
> --
> Renato
>
> // Alternative code to read query parameters in PHP
>
> function _ParseQueryString( )
> {
>    $parameters = array();
>
>    // See if there is any raw post
>    $raw_post = '';
>
>    if ( $fp = fopen('php://input', 'r') )
>    {
>        while ( $data = fread($fp, 4096) )
>        {
>            $raw_post .= $data;
>        }
>
>        fclose($fp);
>    }
>    else
>    {
>        // raise an error here...
>    }
>
>    // Concatenate query string and raw post before splitting
>    $raw_input_items = split('&',
> $_SERVER['QUERY_STRING'].'&'.$raw_post);
>
>    foreach ( $raw_input_items as $input_item )
>    {
>        // split into name/value pair
>        if ( $input_item != '' )
>        {
>            $item = split('=', $input_item);
>
>            $key = urldecode($item[0]);
>
>            $value = (empty( $item[1] )) ? '' : urldecode($item[1]);
>
>            if ( ! isset($parameters[$key]) )
>            {
>                $parameters[$key] = $value;
>            }
>            elseif ( ! is_array($parameters[$key]) )
>            {
>                $first = $parameters[$key];
>                $parameters[$key] = array();
>                $parameters[$key][]= $first;
>                $parameters[$key][]= $value;
>            }
>            else
>            {
>                $parameters[$key][]= $value;
>            }
>        }
>    }
>
>    return $parameters;
>
> } // end of function _ParseQueryString
>
> On 17 Jul 2007 at 12:11, Wouter Addink wrote:
>>
>> Hi Donald,
>> It is true that it depends on the processing software, but I think it
>> is not standard behavior and therefore I would not recommend it. It
>> is also implemented differently in Tapirlink. The reason is that
>> Tapirlink uses PHP and inPHP superglobals ($_GET or
>> $_REQUEST)return only he last kvp parameter if there are more with
>> the same name. An alternative could be to get the wholequery
>> stingwith a server variable ($_SERVER[QUERY_STRING])and to parse
>> the parameters with a regex, but that sounds not very attractive to
>> me, as it depends on the used webserver if this variable is available
>> and returned correctly.
>>     ----- Original Message ----- 
>>     From: Donald Hobern
>>     To: Wouter Addink
>>     Cc: tdwg-tapir at lists.tdwg.org
>>     Sent: Tuesday, July 17, 2007 11:54 AM
>>     Subject: Re: [tdwg-tapir] error in tapir specification
>>
>>     Surely it depends on how the software processes the parameters. The
>>     GBIF data portal has adopted precisely this pattern (no square
>>     brackets) to allow users to specify a set of alternative values for
>>     many of the filters on the occurrence web search. The JSP receives
>>     the parameters fine.
>>
>>     Donald
>>
>>     Wouter Addink wrote:
>>     Hi,
>>     I think there is an error in the KVP Inventory examples in the Tapir
>>     specification doc.
>>
>>     Examples like
>> http://example.net/tapir.cgi?op=inventory&concept=http://example.net/s
>> chema1/Country& concept=http://example.net/schema1/Genus
>>     cannot be implemented I think, because concept will not be treated as
>>     an array here and only the last concept would be returned.
>>     this would work:
>> 
>> http://example.net/tapir.cgi?op=inventory&concept[]=http://example.net
>>     /schema1/Country& concept[]=http://example.net/schema1/Genus
>>     regards,
>>     Wouter Addink
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
> 





More information about the tdwg-tag mailing list