Hi Pantelis, All,

chung wrote:
> Hi Nina and Merry Christmas,
>  It's weird that exactly the same request sometimes results in a status
> 200 response while some other times the server
>  responds with a 400 status code. I attach the html that is returned
>   

This time it seems it is a Restlet issue  (POST body is sporadically
lost when running within Tomcat and under load  - see
http://restlet.tigris.org/issues/show_bug.cgi?id=889 ). They claim it's
fixed in 2.0-M5 , and we are using 2.0-M3 currently.

Upgrading the code to 2.0-M6 took some time, but it's now online and and
the tests are so far successful (all  1000 create feature POST requests
in a loop return 200 OK).

Thanks for spotting this issue - it might as well influence other
services who use Restlet < 2.0-M5 under Tomcat and result in an unstable
behaviour of services.

For those who consider upgrading to 2.0-M6, please note Restlet team has
changed the default mode for matching routes; in order to use the
default behaviour from previous releases, one need to set
"DefaultMatchingMode" and "RoutingMode" as below for all Routers,
otherwise everything might appear broken :
         setDefaultMatchingMode(Template.MODE_STARTS_WITH);
         setRoutingMode(Router.MODE_BEST_MATCH);

Hope this helps,
Nina
> including the message "Nothing to write!
> http://ambit.uni-plovdiv.bg:8080/ambit2".
>  The corresponding request and response headers are:
>
> REQUEST:
> + POST /ambit2/feature/ HTTP/1.1
> + User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15 libssh2/1.2.1
> + Host: ambit.uni-plovdiv.bg:8080
> + Accept: */*
> + Content-type:application/rdf+xml
> + Content-Length: 1413
> + Expect: 100-continue
> + 
>
> RESPONSE:
> - HTTP/1.1 100 Continue
> - HTTP/1.1 400 Bad Request
> - Server: Apache-Coyote/1.1
> - Date: Sat, 26 Dec 2009 14:01:03 GMT
> - Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
> - Accept-Ranges: bytes
> - Server: Noelios-Restlet/2.0m3
> - Content-Type: text/html;charset=ISO-8859-1
> - Content-Length: 4394
> - Connection: close
>
> An example of a successful request/response is:
>
> + POST /ambit2/feature/ HTTP/1.1
> + User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15 libssh2/1.2.1
> + Host: ambit.uni-plovdiv.bg:8080
> + Accept: */*
> + Content-type:application/rdf+xml
> + Content-Length: 1413
> + Expect: 100-continue
> + 
> - HTTP/1.1 100 Continue
> - HTTP/1.1 200 OK
> - Server: Apache-Coyote/1.1
> - Date: Sat, 26 Dec 2009 14:02:51 GMT
> - Location: http://ambit.uni-plovdiv.bg:8080/ambit2/feature/13174
> - Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
> - Accept-Ranges: bytes
> - Server: Noelios-Restlet/2.0m3
> - Content-Type: text/html;charset=ISO-8859-1
> - Content-Length: 53
> - 
> * Connection #0 to host ambit.uni-plovdiv.bg left intact
> * Closing connection #0
> http://ambit.uni-plovdiv.bg:8080/ambit2/feature/13174
>
>
>
> Best wishes,
> Pantelis
>  
>
> On Fri, 2009-12-25 at 14:51 +0200, Nina Jeliazkova wrote:
>
>   
>> Hi Pantelis,
>>
>> Your RDF is fine, and in fact the feature is created successfully (and
>> was also accessible under
>> http://ambit.uni-plovdiv.bg:8080/ambit2/feature/13149 ). 
>>
>> The problem turns out to be a Tomcat 6 peculiarity when handling
>> URLs , containing encoded slashes, like the one below
>>
>>
>>         http://ambit.uni-plovdiv.bg:8080/ambit2/feature/http%3A%2F%
>>         2Fother.com%2Ffeature%2F200Default 
>>
>>
>> Restlet handles these kind of URLs fine, junit tests for this also run
>> fine , but once the code is deployed under tomcat, it fails to
>> retrieve the feature under URL above and instead returns "HTTP/1.x 400
>> Invalid URI: noSlash". The Tomcat 6 behaviour for handling URLs with
>> encoded slashes is controlled via a Java system property , as
>> described in [1] and [2]. 
>>       * org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH: true|
>>         false 
>> Setting the property to "true" fixes the issue you've encountered, but
>> is considered a security threat (under specific settings).   (The
>> security threat could also be valid for other servers as well, not
>> only for Tomcat).
>>
>> To summarize, now we have set the above setting to true and the
>> problem should be resolved. But in general we should avoid including
>> encoded slashes in URLs (I will be changing the code sending feature
>> URLs upon creation).  
>>
>> On another note, avoiding slashes in URIs makes impossible using
>> InChIs  as compound ID as in e.g. /compound/InChI%3D1%2FCH2O%2Fc1-2%
>> 2Fh1H2 , so it would be better if specified as query parameters, e.g.
>> http://ambit.uni-plovdiv.bg:8080/ambit2/compound/?search=InChI%3D1%
>> 2FCH2O%2Fc1-2%2Fh1H2
>>
>> [1]
>> http://old.nabble.com/HTTP-1.x-400-Invalid-URI:-noSlash-td15005787.html 
>> [2] http://tomcat.apache.org/security-6.html
>>
>> Best regards,
>> Nina
>>
>> chung wrote: 
>>
>>     
>>> Hi Nina,
>>>  According to the API, one can post an rdf representation of a feature
>>> to a feature service to have a new Feature created. So I made an
>>> experiment using the following curl command:
>>>
>>> curl -X POST -H 'Content-type:application/rdf+xml' --data-binary
>>> @/path/to/feature.rdf http://ambit.uni-plovdiv.bg:8080/ambit2/feature
>>>
>>> The content of feature RDF is:
>>>
>>> <rdf:RDF
>>>     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>     xmlns:ot="http://www.opentox.org/api/1.1#"
>>>     xmlns:owl="http://www.w3.org/2002/07/owl#"
>>>     xmlns:dc="http://purl.org/dc/elements/1.1/"
>>>     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
>>>     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > 
>>>   <rdf:Description rdf:about="http://purl.org/dc/elements/1.1/creator">
>>>     <rdf:type
>>> rdf:resource="http://www.w3.org/2002/07/owl#AnnotationProperty"/>
>>>   </rdf:Description>
>>>   <rdf:Description rdf:nodeID="A0">
>>>     <owl:sameAs rdf:resource="http://other.com/feature/200"/>
>>>     <dc:creator
>>> rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://opentox.ntua.gr</dc:creator>
>>>     <rdf:type rdf:resource="http://www.opentox.org/api/1.1#Feature"/>
>>>   </rdf:Description>
>>>   <rdf:Description rdf:about="http://other.com/feature/200">
>>>     <rdf:type rdf:resource="http://www.opentox.org/api/1.1#Feature"/>
>>>   </rdf:Description>
>>>   <rdf:Description rdf:about="http://www.opentox.org/api/1.1#Feature">
>>>     <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
>>>   </rdf:Description>
>>> </rdf:RDF>
>>>
>>> This RDF was generated using the following code:
>>>
>>>
>>>
>>> OntModel featureModel = OT.createModel();
>>>         Individual feature =
>>> featureModel.createIndividual(featureModel.getOntClass(OT.Class.Dataset.getURI()));
>>>
>>> feature.addRDFType(OT.Class.Feature.createProperty(featureModel));
>>>
>>> feature.addProperty(featureModel.createAnnotationProperty(DC.creator.getURI()), featureModel.createTypedLiteral("http://opentox.ntua.gr"));
>>>
>>> feature.setSameAs(featureModel.createResource("http://other.com/feature/200", OT.Class.Feature.getResource()));
>>>         OT.Class.Feature.createOntClass(featureModel);
>>>
>>> *** The operation is successful (the server responds with a status code
>>> 200-OK), a URI is returned for the generated feature which is
>>> http://ambit.uni-plovdiv.bg:8080/ambit2/feature/http%3A%2F%2Fother.com%
>>> 2Ffeature%2F200Default , but the result of the following request: 
>>>
>>> curl -v -H 'Accept:application/rdf+xml'
>>> http://ambit.uni-plovdiv.bg:8080/ambit2/feature/http%3A%2F%2Fother.com%
>>> 2Ffeature%2F200Default 
>>>
>>> returns an empty representation and a status code 400 - Bad Request. 
>>>
>>>
>>>
>>> Is there a problem with the RDF I posted? Could you provide an example
>>> of how can one create a new Feature?
>>>   
>>>       
>>     
>>> Best Regards,
>>> Pantelis
>>>   
>>>       
>>     
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development