Re: Incorrect resources being used at for the request?
Hello Barrie,
you should use two instances of SharedSecretGuard.
Or if you want to secure a whole hierarchy or uri templates, you can
define somtehing like that (not tested) :
Router top = *new* Router(getContext());
//Define the hierarchy of URI templates for user resources.
Router user = *new* Router(getContext());
user.attachDefault(UserResource.*class*);
user.attach(/programs/{program}, UserProgramResource.*class*);
Guard sharedSecretGuard = *new* SharedSecretGuard(getContext(),
);
sharedSecretGuard.setNext(user);
top.attach(/users/{username}, sharedSecretGuard);
Best regards,
Thierry Boileau
I have this defined:
Router top = *new* Router(getContext());
Guard sharedSecretGuard = *new* SharedSecretGuard(getContext(),
);
sharedSecretGuard.setNext(UserResource.*class*);
top.attach(/users/{username}, sharedSecretGuard);
sharedSecretGuard.setNext(UserProgramResource.*class*);
top.attach(/users/{username}/programs/{program},
sharedSecretGuard);
and sometimes it decides to use the UserProgramResource to handle a
request made to:
/users/user1
Instead of UserResource
Have you seen this behavior before?
Barrie Selack
Rite Aid Corporation
Disclaimer: This e-mail message is intended only for the personal use of
the recipient(s) named above. If you are not an intended recipient, you
may not review, copy or distribute this message. If you have received this
communication in error, please notify us immediately by e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or distributed
without this statement.
Re: Attribute and URI patterns
Hi
Have you tried to remove the last question mark in your DELETE router uri
template?
Actually, it is not necessary to declare the query part (anything after ?)
in the uri template. If you do not do this, you can still get the query name
and value from Resource of request.getResourceRef().
On Sat, Apr 12, 2008 at 3:54 AM, Bao,Sam [EMAIL PROTECTED] wrote:
I'm trying to attach two different URI patterns to the same resource so
that I can use different patterns for GET, POST, PUT, DELETE However, what
I'm currently doing only GET works, and the attributes are null in DELETE.
I'm using the representations in the POST and PUT, so that part seems fine
to me right now. Any advice for GET and DELETE? This is what I'm doing
right now
Router resultRouter = new Router(getContext());
resultRouter.attach(/result, ResultResource.class); //initial route
resultRouter.attach(/result/{getId}, ResultResource.class); //route for
GET with a getId attribute
resultRouter.attach(/result/{deleteId}/{deleteVersion}?,
ResultResource.class); //route DELETE with a deleteId and a deleteVersion
attribute
resultRouter.attach(/result?{method}, ResultResource.class); //route for
POST with a method attribute
With the above code, in the GET, I'm able to use the getId attribute, but
in the DELETE, the deleteId and deleteVersion attributes don't exist, and
thus null.
Any help or point me in the right direction, would be mucho appreciated.
Thanks.
--
CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities
laws. Unauthorized forwarding, printing, copying, distribution, or use of
such information is strictly prohibited and may be unlawful. If you are not
the addressee, please promptly delete this message and notify the sender of
the delivery error by e-mail or you may call Cerner's corporate offices in
Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
--
Cheers,
Keke
-
We paranoid love life
Re: Unit testing code coverage
Hi Sam, I've just refactored my JUnit TestCase base class to be used independently of JAX-RS. Take a look at project org.restlet.test (only in SVN trunk), class org.restlet.test.jaxrs.server.RestletServerTestCase. You don't need to take a look into the other classes in this package. Subclass RestletServerTestCase and wrote test* methods as for every JUnit test. You may use #setUseTcp(true / false) to indicate, if you want real tcp access (slow) or direct application access (sometimes only nearly real). You may also change the initial value in RestletServerTestCase. You should use the accessServer methods to access the server. So, if you don't understand the result, test with real TCP; if you found a bug in the RestletServerTestCase, let me know, at the best with a test case reproducing it. The setUp() method automaticly starts the server for every method and tearDown() will stop it. So you must ensure to call super.setUp() / super.tearDown() if you override them. Take a look into it and let me know, what is not clear, so I will add more javadoc to methods with not enough javadoc ... I'll be happy about feedback. Perhaps I can not answer the rest of today, but tomorrow I have time for it. best regards Stephan Stephan Koops wrote: [...] BTW: It's not required that you use a real TCP client for testing: You can give the application directly your requests. So you save a LOT of time, because you save the time to start the TCP-ServerSocket, serializing requests and so on. I should refactor that out of my JAX-RS test case class, because it is combined with services for JAX-RS testing. best regards Stephan
RE: Incorrect resources being used at for the request?
Hi Barrie,
You can also attach the router to your guard and the resources to the
router. I think that it nicely covers your use case.
SharedSecretGuard
|
+--Router
|
+--UserResource
|
+--UserProgramResource
Best regards,
Jerome
-Message d'origine-
De : Barrie Selack [mailto:[EMAIL PROTECTED]
Envoyé : lundi 14 avril 2008 14:04
À : discuss@restlet.tigris.org
Objet : RE: Incorrect resources being used at for the request?
Thierry,
Thanks. I'll try the separate way first. But I'd think it
would be nice to officially allow a hierarchy of resources
on a Guard. Maybe this can be a feature request for the next release.
Regards,
Barrie Selack
Rite Aid Corporation
-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Monday, April 14, 2008 4:01 AM
To: discuss@restlet.tigris.org
Subject: Re: Incorrect resources being used at for the request?
Hello Barrie,
you should use two instances of SharedSecretGuard.
Or if you want to secure a whole hierarchy or uri templates, you can
define somtehing like that (not tested) :
Router top = *new* Router(getContext());
//Define the hierarchy of URI templates for user resources.
Router user = *new* Router(getContext());
user.attachDefault(UserResource.*class*);
user.attach(/programs/{program}, UserProgramResource.*class*);
Guard sharedSecretGuard = *new* SharedSecretGuard(getContext(),
);
sharedSecretGuard.setNext(user);
top.attach(/users/{username}, sharedSecretGuard);
Best regards,
Thierry Boileau
I have this defined:
Router top = *new* Router(getContext());
Guard sharedSecretGuard = *new*
SharedSecretGuard(getContext(),
);
sharedSecretGuard.setNext(UserResource.*class*);
top.attach(/users/{username}, sharedSecretGuard);
sharedSecretGuard.setNext(UserProgramResource.*class*);
top.attach(/users/{username}/programs/{program},
sharedSecretGuard);
and sometimes it decides to use the UserProgramResource to handle a
request made to:
/users/user1
Instead of UserResource
Have you seen this behavior before?
Barrie Selack
Rite Aid Corporation
--
--
Disclaimer: This e-mail message is intended only for the
personal use of
the recipient(s) named above. If you are not an intended
recipient, you
may not review, copy or distribute this message. If you
have received this
communication in error, please notify us immediately by
e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or
distributed
without this statement.
Disclaimer: This e-mail message is intended only for the
personal use of
the recipient(s) named above. If you are not an intended
recipient, you
may not review, copy or distribute this message. If you have
received this
communication in error, please notify us immediately by
e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or
distributed
without this statement.
Interesting behaviour of restlet maven repo -- probably a bug
Hi there, i noticed an interesting behaviour of the restlet powered maven repository on http://maven.restlet.org/ Since it is powered by latest 1.1M3 (according to response headers), it seems it is a bug in restlet.org framework. To reproduce: Do in a browser/wget/whatever the following request: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 And youll get the SHA1 checksum as should -- OK But by doing request to this: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1? (yes, a ? at the end without req params), the JAR file is served -- BAD -- Thanks, ~t~
Re: Interesting behaviour of restlet maven repo -- probably a bug
I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thierry, any ideas? On Mon, Apr 14, 2008 at 10:01 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Do in a browser/wget/whatever the following request: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 And youll get the SHA1 checksum as should -- OK But by doing request to this: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 ? (yes, a ? at the end without req params), the JAR file is served -- BAD
Re: Interesting behaviour of restlet maven repo -- probably a bug
This confuses browsers (FFox, Epiphany tested, i believe all Mozilla based ones) and also wget. True, the response header shows the correct served resource (the JAR, not the SHA1), but even then, clients are saving/consuming the response as SHA1 response. ~t~ On Mon, Apr 14, 2008 at 4:07 PM, Rob Heittman [EMAIL PROTECTED] wrote: I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thierry, any ideas? On Mon, Apr 14, 2008 at 10:01 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Do in a browser/wget/whatever the following request: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 And youll get the SHA1 checksum as should -- OK But by doing request to this: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1? (yes, a ? at the end without req params), the JAR file is served -- BAD -- Thanks, ~t~
Re: Interesting behaviour of restlet maven repo -- probably a bug
Hi all, I think it is due to the fact that the sha1 extension is not known by the metadataService. best regards, Thierry Boileau This confuses browsers (FFox, Epiphany tested, i believe all Mozilla based ones) and also wget. True, the response header shows the correct served resource (the JAR, not the SHA1), but even then, clients are saving/consuming the response as SHA1 response. ~t~ On Mon, Apr 14, 2008 at 4:07 PM, Rob Heittman [EMAIL PROTECTED] wrote: I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thierry, any ideas? On Mon, Apr 14, 2008 at 10:01 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Do in a browser/wget/whatever the following request: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 And youll get the SHA1 checksum as should -- OK But by doing request to this: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1? (yes, a ? at the end without req params), the JAR file is served -- BAD
Re: Interesting behaviour of restlet maven repo -- probably a bug
Hi Rob and Tamás, Thierry, any ideas? not yet... I will have a look after my current task. best regards, Thierry Boileau I believe this is the same issue I reported (and haven't been able to fix) with 1.1M3 and query strings, introduced with the new extension based content negotiation. Thierry, any ideas? On Mon, Apr 14, 2008 at 10:01 AM, Tamás Cservenák [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Do in a browser/wget/whatever the following request: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1 And youll get the SHA1 checksum as should -- OK But by doing request to this: http://maven.restlet.org/org/restlet/org.restlet/1.0.9/org.restlet-1.0.9.jar.sha1? (yes, a ? at the end without req params), the JAR file is served -- BAD
RE: Please remove Require-Bundle
This is now fixed, except for the javax.xml.bind and javax.xml.stream bundles which needed the Required-Bundle entry as they are part of JDK 6. Maybe there is a way to fix those one as well. Any idea? Bnd tool home page: http://www.aqute.biz/Code/Bnd Best regards, Jerome -Message d'origine- De : Hendy Irawan [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 avril 2008 23:25 À : discuss@restlet.tigris.org Objet : Please remove Require-Bundle Please replace Require-Bundle with Import-Package. $ unzip -p com.noelios.restlet.ext.jetty_6.1.jar META-INF/MANIFEST.MF Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.5 Created-By: 1.5.0_14-b03 (Sun Microsystems Inc.) Bundle-ManifestVersion: 2 Bundle-Name: Noelios Restlet Engine - Extension - Jetty 6 Bundle-SymbolicName: com.noelios.restlet.ext.jetty Bundle-Version: 1.1 Bundle-Vendor: Noelios Consulting Require-Bundle: com.noelios.restlet;visibility:=reexport,javax.servlet ;visibility:=reexport,org.mortbay.jetty;visibility:=reexport Export-Package: com.noelios.restlet.ext.jetty Name: com.noelios.restlet.ext.jetty Implementation-Title: com.noelios.restlet.ext.jetty_6.1 Implementation-Version: 1.1 Milestone 3 (build 132) Implementation-Vendor: Noelios Consulting At least it should be like this: (wrapped by Bnd tool) $ unzip -p com.noelios.restlet.ext.jetty_6.1.osgi.jar META-INF/MANIFEST.MF Manifest-Version: 1.0 Export-Package: com.noelios.restlet.ext.jetty;uses:=org.mortbay.jetty ,com.noelios.restlet.http,org.mortbay.jetty.bio,org.mortbay.jetty.sec urity,org.restlet.resource,org.restlet,org.restlet.util,org.mortbay.j etty.nio,org.mortbay.jetty.handler,javax.servlet,org.restlet.data,org .mortbay.jetty.ajp,org.mortbay.thread,javax.servlet.http Tool: Bnd-0.0.238 Bundle-Name: Noelios Restlet Engine - Extension - Jetty 6 Created-By: 1.6.0_03 (Sun Microsystems Inc.) Bundle-Vendor: Noelios Consulting Ant-Version: Apache Ant 1.6.5 Bundle-Version: 1.1 Bnd-LastModified: 1207776220268 Bundle-ManifestVersion: 2 Import-Package: com.noelios.restlet.ext.jetty;resolution:=optional,com .noelios.restlet.http;resolution:=optional,javax.servlet;resolution:= optional,javax.servlet.http;resolution:=optional,org.mortbay.jetty;re solution:=optional,org.mortbay.jetty.ajp;resolution:=optional,org.mor tbay.jetty.bio;resolution:=optional,org.mortbay.jetty.handler;resolut ion:=optional,org.mortbay.jetty.nio;resolution:=optional,org.mortbay. jetty.security;resolution:=optional,org.mortbay.thread;resolution:=op tional,org.restlet;resolution:=optional,org.restlet.data;resolution:= optional,org.restlet.resource;resolution:=optional,org.restlet.util;r esolution:=optional Bundle-SymbolicName: com.noelios.restlet.ext.jetty_6.1 Originally-Created-By: 1.5.0_14-b03 (Sun Microsystems Inc.) Name: com.noelios.restlet.ext.jetty Implementation-Vendor: Noelios Consulting Implementation-Title: com.noelios.restlet.ext.jetty_6.1 Implementation-Version: 1.1 Milestone 3 (build 132) -- Hendy Irawan www.hendyirawan.com
RE: [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet
Hi Hendy, Thanks for reporting this. Your suggestion makes sense and is more flexible. I have converted all manifests in SVN trunk. Best regards, Jerome -Message d'origine- De : Hendy Irawan [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 avril 2008 23:01 À : discuss@restlet.tigris.org Objet : [BUG] OSGi manifest, please don't use Require-Bundle, re: com.noelios.restlet.ext.servlet Regarding com.noelios.restlet.ext.servlet JAR in 1.1 M3 Please don't use Require-Bundle manifest header. Please use Import-Package: javax.servlet,javax.servlet.http or others as needed. Require-Bundle hardcodes the bundle name. In my case, I use pax-web, which provides the package javax.servlet.*, however Restlet won't accept it because its bundle name is not javax.servlet (and it can't be, since it's not the javax.servlet bundle). This also applies to all other JARs. Please use Import-Package, not Require-Bundle (at all). Also recommended even for internal RESTlet JARs themselves. Rather than requesting a specific bundle, import specific packages so the user can mix and match as needed. Thank you. -- Hendy Irawan www.hendyirawan.com
Is the Simple HTTP server adequate for a high-traffic API
Hi, I'm using the Simple web server connector (v3.1) in its default configuration for an API that must be able to deal with a high request volume (10-20 requests per second, with each request having a duration of 10ms - 1s each). Is the Simple web server adequate for this? Are there any configuration options I should modify or tweak, and if so, how do I tweak them? Thanks, Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity
RE: Is the Simple HTTP server adequate for a high-traffic API
Hi Ian, Here are the details on the Simple connector: http://www.restlet.org/documentation/1.1/connectors#simple You might also want to consider the standalone Jetty connector which has a strong reputation for performance and scalability. For a benchmark on Restlet 1.0, see: http://www.restlet.org/documentation/1.0/benchmark Best regards, Jerome -Message d'origine- De : Ian Clarke [mailto:[EMAIL PROTECTED] Envoyé : lundi 14 avril 2008 18:23 À : discuss@restlet.tigris.org Objet : Is the Simple HTTP server adequate for a high-traffic API Hi, I'm using the Simple web server connector (v3.1) in its default configuration for an API that must be able to deal with a high request volume (10-20 requests per second, with each request having a duration of 10ms - 1s each). Is the Simple web server adequate for this? Are there any configuration options I should modify or tweak, and if so, how do I tweak them? Thanks, Ian. -- Email: [EMAIL PROTECTED] Cell: +1 512 422 3588 Skype: sanity
RE: riap://host ?
Hi Rob, That's a very interesting proposition. I've entered a RFE for it. Let's try to address it for 1.1 M4: Add RIAP support for virtual hosts http://restlet.tigris.org/issues/show_bug.cgi?id=481 Best regards, Jerome De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : vendredi 11 avril 2008 19:55 À : discuss@restlet.tigris.org Objet : riap://host ? Hi all, We use the riap: pseudoprotocol a *lot*. As some of our projects grow, we are compartmentalizing them into multiple Applications. Some of our use cases then have instances of these Applications instantiated under multiple VirtualHosts. When the VirtualHost layer gets in there, riap://application becomes too granular and riap://component is too broad. Is it possible to introduce a host scheme for riap:// that resolves the reference against the current VirtualHost (or, perhaps, against the Component if there isn't a VirtualHost)? I got as far as adding a RIAP_HOST constant and machinery under LocalReference, but am left head-scratching figuring out what the correct changes would be in ApplicationClientDispatcher and/or ComponentClientDispatcher to make it really work. I find that I don't really understand the VirtualHost plumbing very well. - Rob
RE: SSL configuration
Hi Bruno, Great analysis and propositions! I've been looking into enhancing SSL support in Restlet. The main problem is that the way SSL can be set up is fine for basic cases, but isn't really sufficiently flexible for more serious uses. Some of the problems have been described in http://restlet.tigris.org/issues/show_bug.cgi?id=281 I realize that as well. Here is a summary of the problems: - Client and Server SSL settings ought to be separated. In fact, as far as I'm aware, there isn't really any way to configure SSL on the client side (in particular, usage of client certificates). The idea of allowing the specification of client certificates was discussed recently (I don't remember which RFE now) and it was supposed to use additional/optional connector parameters. Although it should be fine to have a single trust store for client and server, I can think of a few cases where I key stores ought to be distincts (the client certificate a Restlet application uses as a client might not be the same as the server certificate it uses). OK - Server key-stores should be specific to each virtual host. Indeed, the server certificate is specific to a particular host-name (except when using subjectAltNames). Shouldn't it be specific to a given connector instead? In the end, the SSLContext info is used to create SSLServerSocket. But, we can create several instances of the same server connector with different SSL settings, listening on different IP addresses or ports. Then, it is easy to associate a given connector to a given virtual host, by restricting the vhost to the given IP address or port. - Certificate Revocation Lists cannot be handled. CRLs are an important part of PKI. In real-life cases, certificates may have to be revoked before their expiration date (host machine compromised, users not caring for their keys properly, users having their keys stolen, etc.). These things just happen and have to be dealt with. OK Here are a few suggestion on how to make changes in Restlet. This would involve some re-factoring, and I'm not quite sure where and how it's best to do it. Let's have a closer look at it :) - On the server side. It seems that the easiest way is to introduce more flexibility regarding the creation of an SSLContext, which is what the Grizzly and Simple HttpsServerHelpers do anyway from the keystores they get. I've written a (uk.ac.manchester.rcs.sslutils.) SSLContextFactory, which is an abstract class designed to build and initialise SSLContext from sensible default values that may be configured in the concrete factories to allow for specific needs. One of its subclasses is a PKIXSSLContextFactory which makes it possible to load CRLs before creating and initialising the SSLContext. That approach makes sense. In my opinion, having an SSLContextFactory is a rather flexible way to address this problem. I was able to create another type of factory to address the SSL requirements of the RDFauth proposal [1][2] quite quickly (mainly by turning off traditional X.509-related verifications: use with caution!). (Just to clarify, this was just a test for the SSLContextFactory, and I haven't integrated any SSLContextFactories in the Restlet code yet...) Cool! We need something like that in NRE. I think that, instead of passing 'keyStorePath', 'sslProtocol', 'securityProvider', etc. to as parameters to the HttpsServerHelper, passing such an SSLContextFactory would decouple the SSL configuration from these classes. Another way to do this would be to pass an initialised SSLContext directly. The latter would probably be a problem with sub-problem 2 (restarting server sockets), below. I like the ability to set the most common SSL properties as today, as it doesn't involve any specific coding. But we shouldn't add more of those SSL related parameters and instead rely on a SSL Context factory class. There are a few subsequent problems with this: 1. The Jetty connector uses SslSelectChannelConnector and SslSocketConnector, which in effect also build their own SSLContexts from a set of parameters (keystores, etc.), but do not support a method such as setSSLContext(...) and are not sufficiently flexible to set up CRLs. They seem to have the same problem as the current HttpsServerHelpers in Restlet. Jetty, used without Restlet, supports some configuration, in that the SslSocketConnector may be sub-classed and used when configuring Jetty [3]. It's not clear to me how this would work with the NIO connector. If I may be optimistic, I suppose it could be envisaged to submit patches for Jetty to support some setSSLContext in these two classes. I've looked at the code, and it seems feasible. In addition last time I submitted a (small) patch for Jetty, I was impressed by how quickly it was handled. I think it would be worth discussing it on the Jetty lists to see if this could be done. Cool. Do you have a
Downloading Audio file using Restlet
Hi All, I am in the process of writing an application which reads a voice message from INBOX (stored as .wav file) . I have provide an interface to user where he can access his INBOX and download the messages in the INBOX. The message could be a voice message or a text message. I am not sure how can I implement this using restlet. The goal here is that user should be able to download the message as .wav file. I read the contents from the INBOX . I am writing a DownloadRestlet which would interact with the backend systme to read the voice message . Am done with that part but am not sure how to send it back to the Client and how can client download it as .wav file (He should be able to play it say windows media player). Your help would be highly appreciated. Thanks Nilesh
Re: Downloading Audio file using Restlet
You should return a FileRepresentation or a StreamRepresentation with the data and the appropriate media type. I think MediaType.AUDIO_WAV would work On Mon, Apr 14, 2008 at 5:19 PM, Nilesh Vyas [EMAIL PROTECTED] wrote: Hi All, I am in the process of writing an application which reads a voice message from INBOX (stored as .wav file) . I have provide an interface to user where he can access his INBOX and download the messages in the INBOX. The message could be a voice message or a text message. I am not sure how can I implement this using restlet. The goal here is that user should be able to download the message as .wav file. I read the contents from the INBOX . I am writing a DownloadRestlet which would interact with the backend systme to read the voice message . Am done with that part but am not sure how to send it back to the Client and how can client download it as .wav file (He should be able to play it say windows media player). Your help would be highly appreciated. Thanks Nilesh
