Ignoring incomplete HTTP headers
I was wondering whether it was possible to configure Restlet to ignore incomplete HTTP headers when performing a request on a remote URI. While using Restlet to crawl some sites, I've come across a fair amount of URIs that declared an empty Pragma header (Pragma:). This causes the query to fail, while it could simply be logged as a warning and ignored. Is there any way to configure this behaviour, or is it impossible for Restlet to access remote resources who don't adhere to the HTTP specifications to the letter ? Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651541
RE: Problem with attributes in Restlet 2.0
Hello Thierry, I've changed the router query matching mode as you suggested me and it works perfectly! Thank you very much for your help. Best regards. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Problem-with-attributes-in-Restlet-2-0-tp5341461p5465010.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651609
Re: restlets : communicating in SSL with tomcat
Hi Bruno, It's well working , thanx... To complete your post, below is a client code for the example we made : Context ctx = new Context(); Client client = new Client(ctx, Protocol.HTTPS); ClientResource service = new ClientResource( https://192.168.2.199/./status;); ctx.getParameters().add(truststorePath,C:/Program Files/Java/jre6/lib/security/mycacerts.jks); ctx.getParameters().add(truststorePassword,our pswd); ctx.getParameters().add(truststoreType,JKS); service.setNext(client); Representation rep = service.get(); regards Xavier 2010/8/25 Bruno Harbulot bruno.harbu...@manchester.ac.uk On 25/08/10 13:53, Xavier Méhaut wrote: Hi Bruno, Actually our architecture is the following : A PC runs a restlet server locally (withou a servlet container); the resources served by this server call themselves other restlets which are located into another restlet serveron another PC, but this restlet server one is hosted in Tomcat with SSL setted. The problem occurs when trying to call these remote restlets from the first PC. SSL is managed by tomcat and the certificate has been generated by java keygen. Ah, this makes sense. When you say the certificate has been generated by java keygen, presumably, you haven't sent the certificate request to a Certification Authority, so you're effectively using a self-signed certificate on your Tomcat server (presumably, you meant keytool instead of keygen too?). There's nothing wrong with that (although this could become an issue if you expect other clients to connect). However, for the client to be able to connect, you need to tell it to trust your server's certificate explicitly. This means that the trust store you're using on the client side needs to contain this self-signed certificate. The default trust store in Java is usually in $JAVA_HOME/lib/security/cacerts (and the default password is changeme). I wouldn't necessarily modify that file, but you can take a copy of it and import the certificate you've generated on the server into it. * On the server: 1. Find the alias you need from the keystore (otherwise, the default will be mykey: keytool -list -keystore keystore.jks You should see a list like this: Certificate fingerprint (MD5): 5B:91:3D:BB:A7:0D:04:F9:92:A0:79:0E:EA:30:45:6A the alias name, 25-Aug-2010, PrivateKeyEntry, 2. Export the certificate: keytool -exportcert -keystore keystore.jks -alias the alias name -file servercert.der (Note that you only export the certificate here, not the private key, which is not to be distributed.) * On the client: 1. It's not strictly required, but I would copy $JAVA_HOME/lib/security/cacerts to a file that doesn't affect the whole system, let's say mycacerts.jks. 2. Import the server certificate into that store: keytool -importcert -keystore mycacerts.jks -trustcacerts -file servercert.der (Optionally, use '-alias some alias name' if you want it to be easier to identity later on in the list. I'd go for the host name there, but it's just an internal indication in the store.) 3. Configure your Restlet client to use that as a trust store. If you think it's a good idea to use this as a trust store across everything that runs within that JVM, you can use the javax.net.ssl.trustStore properties. Otherwise, you can set it on a per-connector basis, using the Context parameters: parameters.add(truststorePath, pathmycacerts.jks); parameters.add(truststorePassword, password); // parameters.add(truststoreType, JKS); Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651208 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651698
RE: Problems with hanging client calls
Hi Rickard, Yes, we will definitely fix this issue. Thierry will likely look at it tomorrow. Using other connectors is just a workaround. This internal connector has increasing importance for our users so we are working hard on improving it at each release. FYI, we are working in the Restlet Incubator on an enhanced internal connector fully leveraging non-blocking NIO to reduce thread usage and increase scalability/throughput. Initial benchmarks for simple cases show results close to Jetty (even slightly better). It will be part of version 2.1. See this wiki page for details: NIO connectors http://wiki.restlet.org/developers/172-restlet/354-restlet.html Best regards, Jerome -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Rickard Öberg [mailto:rickardob...@gmail.com] Envoyé : mercredi 25 août 2010 09:41 À : discuss@restlet.tigris.org Objet : Re: Problems with hanging client calls On 2010-08-24 21.13, Thierry Boileau wrote: Hello Rickard, to my mind, this should be fixed by using the httpclient connector (or net also). Adding a connector to your application is explained here: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/325-restlet/37- restlet.html Thanks, we will look into that. But shouldn't the default one work properly? Are you looking into fixing this as well? regards, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2650942 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651837
Re: Wrong @Get method is called after negotiation
I've had the same issue. The only workaround I've found is a bit cumbersome but
works:
@Get(json|html)
public Representation getRepresentation(Variant variant) {
if(variant.getMediaType().equals(MediaType.APPLICATION_JSON)
}
I'm not sure whether that's a regression or the intended behaviour...
Nicolas
On 24 Aug 2010, at 08:41, webp...@tigris.org wrote:
In my ServerResource impl (on official restlet 2.0.0 GAE edition) I've got
two annotated methods:
@Get(json)
public Representation getJson() { ...
and
@Get(html)
public Representation getHtml() { ...
When testing the resource with:
curl -v -H 'Accept: application/json'
the result is that getHtml is called returning text/plain
So it seems the annotaion/negotiation isn't working... what could be causing
this?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2650559
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651853
