Netty extension for 304 support with restlet
hi,everybody,
I was planning to make my apis support 304 response with restlet and
netty extension(2.0.11). However, netty extension has a bug for dealing with
restlet response of 304(with null entity). I debuged and found the code with
this bug:
File: HttpRequestHandler.java
Line: 215
Code:
if (responseEntity != null) {
if (nettyResponse.isChunked()) {
nettyResponse.setContent(null);
future = ch.write(nettyResponse);
ch.write(new ChunkedStream(restletResponse
.getEntity().getStream()));
} else {
ChannelBuffer buf = dynamicBuffer();
buf.writeBytes(responseEntity.getStream(),
(int)
responseEntity.getAvailableSize());
nettyResponse.setContent(buf);
future = ch.write(nettyResponse);
}
}
Explanation:
for 304 response, restlet set the entity with null value, and as a
result nettyResponse will never get sent.
hope this bug will be fixed in netty extension 2.1. Restlet core can also
fix this bug by set 304 entity to empty representation not null.
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/Netty-extension-for-304-support-with-restlet-tp7316840p7316840.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2926521
Downloading Libraries
I've been trying for a couple days now, and I can't completely download from: http://www.restlet.org/downloads/2.2/restlet-jee-2.2snapshot.zip Is there a known problem? Is this the correct link? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2926365
RE: Re: Netty, JSON and Chunked Encodings
> Hello Grant,
>
> the usage of the chunk encoding is perfectly normal and must be supported
> by HTTP servers and clients (except GAE...). I guess this reveals a problem
> with the Netty extension, which should correctly parameter the underlying
> netty http server in such case.
I'm not sure I follow. The problem isn't that it doesn't send chunked
encoding. It's that it thinks all JSON messages are chunked due to the
JacksonRepresentation not setting the size value correctly.
> Having said that, I propose you to simplify your code, as there is no need
> to specify the netty connector (this is due to a kind of magic that I will
> explain later).
>
> Component component = new Component();
> component.getServers().add(new Server(Protocol.HTTP, port));
I actually have an if clause in there to check whether to use SSL or not (I
snipped it out of the msg b/c it didn't seem relevant.
Would simply specifying HTTP or HTTPS automagically still do the right thing
and pick the appropriate Netty service?
>
> Injector injector = Guice.createInjector(new APIModule(apiClass));
> API theAPI = injector.getInstance(apiClass)
> // Then attach it to the local host
> component.getDefaultHost().attach("/api", theAPI);
> // Now, let's start the component!
> component.start();
>
> At this time, you are only required to add to the classpath the jar of the
> netty extension (org.restlet.ext.netty.jar), and the jar(s) of the
> libraries it depends on.
> At runtime, the engine detects the presence of an HTTP server connector,
> instantiates it, and voila! This magic is based on a simple mechanism
> integrated in the JDK, made public since jdk 6 and called "ServiceLoader".
>
> As a matter of test, I suggest you to remove the workaround (which is
> useless) and just replace the netty connector by the jetty one : you are
> only required to update your classpath.
>
> I make some tests also and keep you informed.
>
> Best regards,
> Thierry Boileau
>
> My attempted patch at this, which appears to work at first blush, is at
> > https://github.com/lucidimagination/restlet-framework-java/tree/2.0.11-patch
> >
> > --
> >
> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2924788
> >
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2926362
OAuth extension - update from draft-10 to latest
Hi,
I'm planning to implement my OAuth 2 authorization server and I'm looking for
library I can use to implement it. I found the OAuth extension easy and I
managed to develop one so good work, thank you. Now I'm looking into the
details and I try to make a flexible and secure implementation. There are some
constraints in the implementation that does not let me do without many
workaround. So I hope I can get some help about what the close feature plan. I
see Kristoffer Gronowski is working on the extension so I can offer my help and
contribute back if he needs help. My goal is to support the latest draft (One
reason is http://developers.facebook.com/docs/oauth2-https-migration/) and
following the http://kantarainitiative.org/confluence/display/uma/Home
initiative.
The specification has six authentication Flow and it's open for custom ones and
the current public "enum Flow { NONE, PASSWORD, REFRESH;}" does not let me
extend. I also have many other suggestion we can discuss if I can use this
extension to implement my server with this extension.
Regards
Laszlo Hordos
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2926213
Re: Post problems when using Restlet Javascript Edition...
Quick update - I put in explicit media types for the @Post() annotations on
my implementing classes, e.g.:
@Post("json")
public Representation acceptJson(String jsonString) {
And that has fixed the problem both when going through tcpmon and without
tcpmon involved. I wasn't able to figure out if tcpmon changes the headers.
All is good now - thanks again for your help!!
RB
On Thu, Feb 23, 2012 at 1:00 AM, Thierry Templier [via Restlet Discuss] <
ml-node+s1400322n7311238...@n2.nabble.com> wrote:
> Hello Richard,
>
> I answer in the message content.
>
> Thierry:
>
> Thanks so much for your help. The short version is that the latest
> Restlet JS code (plus one change in my code) fixes my problem with post().
> There is one "strangeness" that I will describe below, but it isn't a big
> problem for me at this point, but I will describe it below in case you
> think it matters. Again, thank you!! And, please let me know if there is
> any testing that I can do for you.
>
> You're welcome! Thanks very much for your proposal!
>
> Details...
> I installed the new scripts. Only part that confused me was that I
> initially took restlet-browser.js from:
> * modules\org.restlet.js\src\dist\restlet-browser.js
> But that was the wrong file, I had to use:
> * tests\org.restlet.js.tests\src\browser\static\restlet\restlet-browser.js
> if that is what was intended, all is fine.
>
> The restlet-browser.js in the modules/org.restlet.js/src/dist folder is
> the assembly file that selects which files to include in the Restlet JS
> edition for browser. After having run Ant with build.browser task, the js
> file for the edition can be found in the
> modules/org.restlet.js/target/browser directory.
>
> Once I put in the right restlet-browser.js, I ran my test and got a 415
> error. So I ran the test through tcpmon - and when going through tcpmon -
> it worked! But the mystery was that when going through tcpmon, the server
> side method "acceptJava()" was being called, not "acceptJson()". I changed
> the ordering as per your email, but that still didn't fix my problem (but I
> did discover that the re-ordering is indeed necessary, but that is getting
> ahead of the story).
>
> Do you know if tcpmon updates the request by adding or removing some HTTP
> headers?
>
>
> At this point I had:
> public interface CommitmentsResource {
> @Post("json")
> public String acceptJson(String value); // For JSON
> @Post("form")
> public Representation accept(Form form); // For HTML form
> @Post()
> public Representation acceptJava(Commitment commitment); // For Java post
> }
>
> And...
> public class CommitmentsServerResource extends WadlServerResource
> implements CommitmentsResource {
> @Post
> public Representation acceptJava(Commitment commitment) {
> }
> @Override
> public String acceptJson(String value) {
> }
> @Override
> // This is the code that actually handles posts that come from forms and
> http posts
> public Representation accept(Form form) {
> }
> I had the thought that acceptJava was the one being called since it was
> the only one with the @Post annotation. I changed the @Override
> annotations to @Post. And then the Javascript post was handled by the
> acceptJson method (which I then fleshed out and changed to return a
> Represenation).
>
> Everything would be perfect at this point, except for the "strangeness".
> Now when I run the test through tcpmon, I get a 415 error there. The call
> does make it to the server, since I get an error in the console along the
> lines of:
> Feb 22, 2012 3:07:33 PM org.restlet.ext.jackson.JacksonRepresentation
> getObject
> WARNING: Unable to parse the object with Jackson.
> org.codehaus.jackson.map.JsonMappingException: Can not deserialize
> instance of org.restlet.data.Form out of START_OBJECT token
> at [Source: org.restlet.engine.io.UnclosableInputStream@41c7d56b; line:
> 1, column: 1]
> at
> org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163)
> .
>
> And then to try and break my "non-tcpmon" client, I changed the ordering
> of the @Post methods, and that did indeed break things as you had predicted.
>
> I discussed this issue with Restlet team and the problem comes from the
> Jackson extension. In fact, there is a problem when computing scores to
> route to the right method. They're working on this issue...
>
>
> Thanks again!!
> RB
>
> Thierry
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://restlet-discuss.1400322.n2.nabble.com/Post-problems-when-using-Restlet-Javascript-Edition-tp7270413p7311238.html
> To unsubscribe from Post problems when using Restlet Javascript
> Edition..., click
> here
> .
> NAML
