Error with HTTP connection: close header

Question

I had a strange problem with a little relaxation service that I create as an exercise. It is assumed that the application will respond to some XML ( in particular TwiML , since it is designed for Twilio) on HTTP POST, and it works fine for standalone requests. However, at Twilio's request, the answer never ends and it expires. After comparing the traffic coming from Twilio to the one that works (using a fake HTML form), I highlighted the problem in the “Connection: close” header and can play it using only the curl command line. Here is a query that works:

curl -i -H 'Connection: keep-alive' -X POST -d "name=value" http://localhost:8020/hello 

and here is the one that just hangs:

 curl -i -H 'Connection: close' -X POST -d "name=value" http://localhost:8020/hello 

If I kill the server, then the curl says: "(52) An empty response from the server." Here is the code I'm using in ServerResource:

 @Post public Representation hello(Representation repr) { Representation result = new StringRepresentation(("<Response>\n"+ " <Say>Hello. This is a test.</Say>\n"+ "</Response>"), MediaType.APPLICATION_XML); return result; } 

Is there something clearly wrong with what I'm doing here? I am using restlet-2.0, but also tried with 2.1m1 with the same result. I would really appreciate a quick response, as I am in a pinch to finish the exercise.

Answer 1

not sure if you found a solution for your error, but I ran into the same problem in Restlet V 2.0.4.

When you restart using the default server. Here, the server assumes that the response stream is not writable and therefore will not respond with an entity.

As a quick fix, I found

  org.restlet.engine.http.connector.Connection 

and changed the canWrite () method to

 public boolean canWrite() { return ( (getState() == ConnectionState.OPEN) || (getState() == ConnectionState.CLOSING)) && !isOutboundBusy() && (getOutboundMessages().size() > 0); } 

from the original

 public boolean canWrite() { return (getState() == ConnectionState.OPEN) && !isOutboundBusy() && (getOutboundMessages().size() > 0); } 

Not sure if this is a good fix, but after recompiling the recovery module, it now works fine. The problem seems to be that when specifying the HTTP connection: close header, the default thread is in the closed state.

Hope that helps

Joey

See here the problem on the reseller forum

http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2698048

Answer 2

Not sure if this is the case, but here's what to think about:

Restlet very carefully and accurately implements the architectural style of REST. One of the key principles of REST that it implements is a single interface. In an HTTP-based web service, a single interface uses the HTTP GET, PUT, POST, DELETE (and others) operations as they were originally intended. Therefore, to create a resource on the server, when you assign a resource name, you use PUT. To update this resource, you use PUT again. To read this, you use GET. To delete it, use DELETE. POST is reserved for creating a resource when the server assigns a resource name.

So this may be due to mismatch of expectations. POST usually has a view that you send to the server, but this POST does not. Are you reading the full request and closing the server-side connection correctly?