Re: expect/continue handshake

status: https://github.com/restlet/restlet-framework-java/issues/711 Best regards, Jerome 2013/1/16 Ishaaq Chandy [hidden email]http://user/SendEmail.jtp?type=nodenode=7578593i=0 Thanks for the reply Jerome. FWIW, jetty does give you control of the Expect headers - it wait till

Re: expect/continue handshake

Thanks for the reply Jerome. FWIW, jetty does give you control of the Expect headers - it wait till the client actually tries to read the stream before automatically sending back a Continue. http://wiki.eclipse.org/Jetty/Feature/1xx_Responses#100_Continue Ishaaq -- View this message in

Re: expect/continue handshake

Thanks for giving it a go anyway Tim. The fact that that Expectation class exists sort of indicates that someone must have got it working in the past, so yes, further clarification from the restlet guys wouldn't go astray Ishaaq -- View this message in context:

Re: expect/continue handshake

be easier to start by writing the client side of this using the classic Restlet APIs and not the annotation-based API, setting the Expect and Content-Length headers manually and checking the response for a 100 status. --tim On Mon, Dec 10, 2012 at 9:35 AM, Ishaaq Chandy lt; ishaaq@ gt; wrote

expect/continue handshake

Hi all, I have a client app that is communicates using a ClientResource to a ServerResource. The latter is managed using the annotations mechanism - much like what is documented here: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/328-restlet/285-restlet.html The client sends large

RE: Re: org.restlet.lib.com.google.protobuf

Thanks Thierry! Got a follow up question now though. I was looking at documentation at http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/299-restlet.html, trying to figure out how to ensure that my protobuf based converter/representation is used by my Client/ServerResource classes.

org.restlet.lib.com.google.protobuf

Hi, Am interested in setting up Resources that use protobuf messages for data transfer. After some searching around I discovered this: http://maven.restlet.org/org/restlet/jee/org.restlet.lib.com.google.protobuf/2.2/ Is anyone maintaining this? Where is the source? If not, if I were to roll my

Re: content negotiation

If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response ... I guess you *could* argue that this is not a bug as the word SHOULD above

content negotiation

Hi all, So, with restlet 2.0.6, I'm annotating my resource methods like this: @Get(xml) public MyResult getResult() As expected, the annotation is used to do content negotiation. However I was surprised to discover that a client that sends in an Accept header that does not match (for e.g.

Re: fine grained authorization

Thanks, but role-based authorization was not exactly what I was after. When I said instance-specific authorization I meant authorization based on particular resource instances. So, as a crude example, if I have a Resource type called House and I have a role called HouseOwner - not every

fine grained authorization

Hi all, Am using Restlet 2.0.6. Trying to figure out how to implement fine grained authorization on my Resources. The authorization checks need to be instance-specific. According to http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restlet.html, I should be able to leverage

Fine grained authorization

Hi all, Am using Restlet 2.0.6. Trying to figure out how to implement fine grained authorization on my Resources. The authorization checks need to be instance-specific. According to http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restlet.html, I should be able to leverage