Re: How do I get the contents of POST variables?
I thought that the entity is what I should be looking at, thanks! I know that they are different, but some frameworks already provide a single call to fetch the data, and I have found it useful in the past. -- -a Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts. -- L. Stein On Jun 19, 2009, at 5:08 AM, Thierry Boileau wrote: Hello, if entity is the Representation sent via the POST request, you can parse it with a Form as follow: Form form = new Form(entity); If you want to get the cookies values, just call request#getCookies. For sure, there is a real distinction between the query part of an URI and the content of POSTed entity. The query is part of the identifier of the resource. An entity sent via a POST is a set of data that the resource is asked to take into account in order to act on its current state. It seems preferable keep this distinction. best regards, Thierry Boileau I can get GET variables via the getQueryAsForm method for a resource reference, but how do I get POST variables? Also, it would be nice to have a getVariable() method that returned a series comprised of GET, POST, and COOKIE keys and values. Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363464 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363489
Premature EOF / Broken Pipe
Hi, I'm having a communications problem between a client/server application both using Restlet 1.1.1 (and since upgraded to 1.1.5). The client and server are both running on Fedora 10, OpenJDK-6 build 14. The client posts a status resource message to the server to exchange status information at regular intervals. The message send works most of the time. But, some times I'll get an exception on both the server and client side. The client side throws a Premature EOF IOException while trying to parse the response entity as Sax; while the server side sees an IOException with the message Broken Pipe. (stack traces are attached using Restlet 1.1.1) If the client sends the status resource message once every three minutes, I'll hardly ever get this exception pair. If I send it every 10 seconds, the error rate is ~ 3%. At 5 second intervals, the error rate is in the 25-50% range. I was first seeing this error going over a wide area connection, but the error will occur on my local area network too. I upgraded to Restlet-1.1.5 from 1.1.1 but that didn't help. :-( Could HTTP caching be biting me here? The POST data doesn't change much from message to message. I'm running out of ideas as to what to look at next for the cause of this problem.INFO: Starting the HTTP client Jun 18, 2009 7:54:02 AM com.noelios.restlet.http.HttpClientCall getResponseEntity INFO: The length of the message body is unknown. The entity must be handled carefully and consumed entirely in order to surely release the connection. ERROR: 'Premature EOF' javax.xml.transform.TransformerException: java.io.IOException: Premature EOF at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:724) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317) at org.restlet.resource.SaxRepresentation.parse(SaxRepresentation.java:189) at com.atilabs.rtikiosk.server.StatusResponseHandler.init(StatusResponseHandler.java:24) at com.atilabs.rtikiosk.server.StatusTransaction.parseResponse(StatusTransaction.java:48) at com.atilabs.rtikiosk.server.Server$1.run(Server.java:122) Caused by: java.io.IOException: Premature EOF at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1719) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipSpaces(XMLEntityScanner.java:1469) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$TrailingMiscDriver.next(XMLDocumentScannerImpl.java:1373) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:624) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:486) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:810) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:740) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:110) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:641) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:712) ... 5 more - java.io.IOException: Premature EOF at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302) at
RE: Premature EOF / Broken Pipe
As a test, I moved the client code to a Windows XP machine. With a five second update rate it fails regularly too, with the same exceptions and stack traces. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363562
RE: 2.0m3 and content negotiation
Hi Bruno,
I was surprised to get your email so I've tried a similar test with SVN
trunk (no change in this area since 5104) and it works just fine. I never
get 406 because the conneg algorithm always try to fall-back on one of the
variants if it exists.
The test file uses is attached.
Regarding annotation values, we can't unfortunately use constant class
instances, only primitive types and enumerations...
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:n...@ger.gmane.org] De la part de Bruno Harbulot
Envoyé : jeudi 18 juin 2009 14:37
À : discuss@restlet.tigris.org
Objet : Re: 2.0m3 and content negotiation
Hi Jerome,
I've just upgraded to revision 5104. (I've have looked in details at the
changes in the code.)
I'm still not clear what should work with annotations. The simple
test-case I'm using tries to do content-type negotiation between
text/plain and application/xml.
public class TestResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
setNegotiated(true);
}
@Get(xml)
public Representation toXml() {
return new OutputRepresentation(MediaType.APPLICATION_XML) {
/* ... */
}
}
}
Making a GET request with Accept: text/plain produces a 406 Not
Acceptable (which makes sense).
However, I get the same error with Accept: text/xml, application/xml.
I do get a successful response (200 with the XML representation
intended) with Accept: */* (however, there's nothing being negotiated
since there's only @Get(xml) here).
I believe the problem comes from the fact that
ServerResource.getAvailableVariants(...) assumes that 'Representation'
implies the media type is going to be application/octet-stream.
This example works as intended when declaring the return type to be
DomRepresentation instead of Representation:
public class TestResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
setNegotiated(true);
}
@Get(xml)
public DomRepresentation toXml() {
return /* some DomRepresentation */
}
}
It seems a bit restrictive not to allow to use Representation and to
expect a specific subclass (as there are more potential media types than
subclasses of Representation).
Regarding the annotation parameters and media types, perhaps it would be
useful to allow for both the extension and the actual media types, for
example @Get(extension = txt) and @Get(mediatype = MediaType.TEXT_PLAIN).
Best wishes,
Bruno.
Jerome Louvel wrote:
Hi Bruno,
Thanks for looking into this part of the code base.
As said in other emails, many enhancements and refactorings were done
recently on ServerResource, ConverterService and content negotiation.
Previously, annotation values weren't taken into account, leading to
strange
results as you observed. They are now taken into account to result
representation, only media types for now based on extensions declared in
MetadataService.
The ConverterService has been enhanced to allow better selection of
ConverterHelpers via a scoring logic. Previously, a converter such as
XStream could convert anything to representation and could prevent other
(more specific) converters from being selected. I think that the target
variant is now better taken into account by existing converters.
Could you have another look at the code and let me know what you think of
the changed recently made?
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23631
56
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363616
TestServerResource.java
Description: Binary data
