Re: VirtualHost configuration
Hi Tal, The hostPort lets you restrict not only the virtual domain name served by your virtual host, but also its port number, so you could have one separate virtual host per port number in theory. The resourcePort could potentially be different from the hostPort if the HTTP request URI was provided in absolute form: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2 The serverPort is a property that restrict your virtual host to the actual listening port of your server socket, which might be different fro the hostPort when using port rerouting. Best regards, Jerome 2013/2/7 Tal Liron tal.li...@threecrickets.com I use virtual hosts a lot, but I almost always use setResourcePort so that applications can work on different ports. I'm wondering: 1) What is setServerPort for? 2) What is setHostPort for? Setting either of these seems to make no different in routing incoming requests. The JavaDocs for VirtualHost are very lean, and could definitely use some more detail! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3047996 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3071509
Re: Apache HttpClient timeouts
Tal, That's correct that those parameters are mostly used on a per connector basis, and not a per request basis. I don't think it is a limitation of Apache HTTP Client which should be able to configure these parameters on a per connection basis, but more a Restlet API limitation. Some room for improvement for RF 3.0 maybe: https://github.com/restlet/restlet-framework-java/issues/815 Best regards, Jerome 2013/11/5 Tal Liron tal.li...@threecrickets.com I know that it's possible to globally configure the socketTimeout parameter for the HttpClientHelper. However, is it really impossible to configure a different timeout per request? In my experimentation, whatever I set in the context for a particular ClientResource is ignored. It seems that the timeout is only initialized once. Is this due to a limitation in Apache HttpClient? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3067933 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3071510
Extensions refactoring (Net, SSL and Core)
Hi all, Quite a bit of changes have been made to RF 2.2 branch (upcoming 2.2 M7 version) in order to solve several issues: - internal NIO-based connectors in org.restlet.jar still lack stability and were moved to an org.restlet.ext.nio module to let them mature further - new internal connectors have been added based on the existing org.restlet.ext.net module (removed) for the client side (java.net.HttpURLConnection) and based on com.sun.net.httpserver for the server-side (HTTP/HTTPS) as we are now on JDK 6 which includes this lightweight web server. - the SSL extension was split into an org.restlet.ext.jsslutils extension for integration with the third-party jSSLutils library, and for the rest moved to either org.restlet.ext.nio for the HTTPS internal connectors, or to the core org.restlet module for the common SSL support classes, removing an extra dependency for many extensions such as Jetty, Simple and Apache HTTP Client. There is now also the CertificateAuthenticator in the org.restlet.security package. An additional benefit will be that Android extension users won't need to manually configure the Net extension anymore to get the HTTP client working. The org.restlet.jar will also be smaller, improving the download size. We still need to work on updating the test suite to ensure that all connectors are properly tested, but almost all test cases now pass with the new internal connector, for those who want to give them a try. Best regards, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3071511
