Re: contributing - areas of interest
hello Bruno, On Tuesday 09 December 2008 08:23:52 Bruno Harbulot wrote: Hi, You might also be interested in RFE 505, which already has a few comments, including pointers to discussions on this mailing list: http://restlet.tigris.org/issues/show_bug.cgi?id=505 indeed! thanks for the pointer. (I doubt I'll be able to follow the discussions in details over the next couple of weeks at least.) Best wishes, Bruno. Raif S. Naffah wrote: hello Avi, On Tuesday 09 December 2008 03:32:54 Avi Flax wrote: On Mon, Dec 8, 2008 at 03:04, Raif S. Naffah [EMAIL PROTECTED] raif.namewrote: i'd like to contribute to this project in my free time. Raif, that's great! Can I suggest RFE 658, Add support for JSecurity? http://restlet.tigris.org/issues/show_bug.cgi?id=658 Since you're interested in security, this might be interesting to you. I'd love to see this one make progress! yah! it's very close to what i had in mind. i'll look closer into JSecurity and may be add my comment to that RFE. Thanks, thanks for bringing JSecurity to my attention! Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =98 1192 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=98 1301 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981535 signature.asc Description: This is a digitally signed message part.
Re: REQUEST FireFox cache control
Hi, perfecto Rob, as usual! cheers, Thierry Boileau Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the transient property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes() http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes%28%29 This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. (which is hopefully correct), FF will only respond as expected if you /also /set no-store. In otherwords, Cache-control: no-cache no-store. See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 no-cache will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use no-store if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using no-store for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use no-store on pages that absolutely must not be reloaded for any reason, but generally use no-cache for good performance combined with good liveness of content. - R -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981564
Running restlet/maven in Tomcat causes CCE
I have a maven/restlet project that works just fine when I launch it with mvn jetty:run. If, however, I launch the same project, unchanged, with mvn tomcat:run, I get: [ERROR] Allocate exception for servlet PytheasRestServlet java.lang.ClassCastException: com.noelios.restlet.ext.servlet.ServerServlet cannot be cast to javax.servlet.Servlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1055) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:619) I assume this is some kind of classloader problem, but I have no idea how to go about tracking it down. Anyone have any suggestions? Thanks, Ian -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981641
RE: REQUEST FireFox cache control
Wow. Thanks for the great, detailed response. I will look at the non-standard header mechanism. And . I concur with you that IE isn't always right. Or worse, for things that you would think would be basic (like content-types, and cache control)-or at least handled consistently by 2008-IE, FF, Opera (and most certainly all others) have different ideas. Cliff Binstock Coyote Reporting _ From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 6:48 PM To: discuss@restlet.tigris.org Subject: Re: REQUEST FireFox cache control Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the transient property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#g etAttributes() This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-fire fox-and-ie-caching/ (which is hopefully correct), FF will only respond as expected if you also set no-store. In otherwords, Cache-control: no-cache no-store. See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 no-cache will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use no-store if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using no-store for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use no-store on pages that absolutely must not be reloaded for any reason, but generally use no-cache for good performance combined with good liveness of content. - R -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981752
Customized 200 level response status codes
I define a customized status code(299) to handle the case of a success request
with no data found. I tried two different ways to set this status code(see
below), but the status code client receives is 404, not 299. There's no place
in my codes to set status to 404, so this 404 must be generated by Resetlet
automatically.
If I change 299 to any 400-level or 500-level code, for example, 499, then it
works fine. Does anyone know why?
If there any way I can set a status of 299?
Thanks.
code
// somewhere define my customized status
public static Status SUCCESS_NO_DATA = new Status(299);
//
public Representation represent(Variant variant) throws ResourceException
{
try {
// ...
} catch (Exception e) {
// OPTION getResponse().setStatus(SUCCESS_NO_DATA, No Data);
// OR
// OPTION 2
throw new ResourceException(SUCCESS_NO_DATA, No Data, e);
}
}
/code
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981976
Re: Customized 200 level response status codes
I know this doesn't answer your question, but doesn't 204 do what you want
already?
--Erik
On Tue, Dec 9, 2008 at 6:58 PM, [EMAIL PROTECTED] wrote:
I define a customized status code(299) to handle the case of a success
request with no data found. I tried two different ways to set this status
code(see below), but the status code client receives is 404, not 299.
There's no place in my codes to set status to 404, so this 404 must be
generated by Resetlet automatically.
If I change 299 to any 400-level or 500-level code, for example, 499, then
it works fine. Does anyone know why?
If there any way I can set a status of 299?
Thanks.
code
// somewhere define my customized status
public static Status SUCCESS_NO_DATA = new Status(299);
//
public Representation represent(Variant variant) throws ResourceException
{
try {
// ...
} catch (Exception e) {
// OPTION getResponse().setStatus(SUCCESS_NO_DATA, No Data);
// OR
// OPTION 2
throw new ResourceException(SUCCESS_NO_DATA, No Data, e);
}
}
/code
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981976
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981980
Re: Customized 200 level response status codes
For pragmatic reasons, unless your application only operates over a network you configure and control, with clients you configure and control, I'd avoid customizing status codes. Browsers, HTTP libraries, proxies, and higher-layer switches may behave in undefined ways when they encounter non-standard codes -- even though they really should behave politely and largely respect the first digit of the code. Here, I would either return 204 as Erik suggests, or return 200 with an empty entity, e.g. an empty document or textual message. Probably the latter, as 204 still confuses some browser-based client libraries and I get a bit tired of explaining what 204 does. That all said, I think what you did should have worked. So I wonder if you didn't hit one of these undefined intermediary behavior issues, and/or maybe a Restlet bug. Which HTTP server connector are you using, and which client are you using to test? Then I can set it up to verify. On Tue, Dec 9, 2008 at 9:58 PM, [EMAIL PROTECTED] wrote: If I change 299 to any 400-level or 500-level code, for example, 499, then it works fine. Does anyone know why? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981982
