I am sometimes getting 102 response from a web server. This response indicates that the server is processing the request but is not the final response for it (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#1xx_Informational). The request(>) response (<) sequence might look like this:
>GET some_url
<HTTP/1.1 102 Processing
<HTTP/1.1 102 Processing
<HTTP/1.1 102 Processing
<HTTP/1.1 200 OK
The server can be considered reliable in the sense that the final response is ultimately sent.
Using LWP::UserAgent (6.02) I can recognise that I've received a 102 using HTTP::Status::is_info() but what I then need to do is consume at least one and maybe more subsequent responses for the original request and I can't see a way to do that once I have the response.
I thought I might be able to do it with a handler (http://metacpan.org/pod/LWP::UserAgent#Handlers) which I use successfully elsewhere, but I can't find a way to force continuing to listen.
I've also looked for a way to turn on "102 awareness" within LWP and just have the library take care of listening for the final response which it then returns, but I can't see that either.
Tell me I'm missing something obvious, please.
Related
I have confusion that, Im using 202 status code, when I receive a POST request from a client (A) and B is processing it , passing the output to another endpoint(C).
In this case I use 202 status code when B receives the request from A.( I have added the sample message flow.)
B is not sending any other response back to A. So is that right using 202 or it should be 200 ?
My understanding is, we use 200 for GET calls, and for POST we use 202 if processing is pending.
Here i have pending the processing and i forward that output to C. Not to A.
So here is my confusion to use 202 or 200 is right?
Edit
If it is a call back endpoint, (eg: in this picture B), would it be appropriate to have 200?
The main purpose of using 202 instead of 200 is for a server to communicate to a client: "From what I can tell, the request looks good. However, we haven't fully dealt with your request yet and we aren't 100% certain it's going to succeed".
So if someone does a request, the server immediately responds and then forwards the request elsewhere, a 202 makes sense to me. If the request fails at the C endpoint, A it will be too late for A to find out about this.
If you respond with 200, it tells a client that the request fully succeeded.
My code is working ok for GET/POST/PUT to/from restApi1 and restApi2.
However, my problem I need to implement HEAD/OPTIONS (no body!) and GET uri1
HEAD/OPTIONS could return 204 or 200 depends on a process status. I am getting error "Stream closed". Sounds like Camel want body bytes, but I don't indend to have it. Even I set ExchangePattern.InOnly or optional etc error occur...
What is correct way to see responses and handle requests WITHOUT body, just statuses exchange?
How to see response from restApi2 on Camel rest("/restApi1").head().route().routeId("id1")
.to("direct:restApi2").routeId("/id1").setHeader(Exchange.HTTP_METHOD,constant("HEAD"))
setExchanggePattern(ExchangePattern.OutOptionalIn).recepientList(simple(restApi2));
I figured it out. Need to set '.convertBodyTo(String.class)' even I don't have a body.
Can a GET request message ever return a HTTP status code of 201?
A conforming HTTP server should never do this. GET is a safe method, and is not supposed to have any side effects.
201 means a new resource was created on the server, which really is a side-effect.
So if a GET results in a 201, something is wrong. However, if you are building a client want to know in advance which success codes you might get, you should simply support every code between 200 and 299 (inclusive) and treat them all as success codes.
Yes. The API has control over what status code to send.
In practice, the status code is meant to communicate the status of the response - so it’s unlikely that a 201 (“Created”) should be returned from a GET request.
201 - created.
We can return code 201 for GET, but normally we use POST to send some data in server. So I don't think it is good to return 201 for GET
I am implementing REST services using Apache-CXF running on servicemix and for that I have a camel route that does some processing, sends the message over queue, process some more and send back the reply. Something like this:
from("direct:start")
.process(A)
.process("activemq:abc")
.process(B);
On this route I have applied some basic validation and exception handler and when I have to stop the route in both cases, I use something like this:
exchange.getOut().setBody(response);
exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE);
I use soap UI, restclient-UI and putty to make http requests and I get proper response body displayed in all of them. Now I wanted to preserve request headers so I made a little change everywhere in the code so that response bodies are set in exchange.getIn() only. For example: in case of validation failure I do:
exchange.getIn().setBody(response);
exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE);
Just with this little change, the rest clients I am using to make request stopped displaying the response body. As per the server logs, response is being generated and also as per the logs in rest client, I am getting the proper response but they are unable to display the response body only in case when I stop the route in between. Normal response is displaying just fine. Only the restclient-UI was considerate enough to show the error as to why they are not displaying body and the error is:
Byte array conversion from response body stream failed.
Diggin deeper, I found the only response header which was there in success response but missing in error response:
Transfer-Encoding chunked
Error response is around 1000 characters long and contains a header called content-length. I am not sure but I think the problem has something to do with this itself. I would really like to play with exchange.getIn but these different kind of responses prepared by camel are confusing me. How can I make sure my camel responses are always displayed properly?
The Content-Length header will be preserved from the original request so you need to remove it so that camel cxf can work out the new body length on the response and set Content-Length with that.
I have a REST API where the GET request can take 10-20 seconds. So I usually return a 202 code with a location like http://fakeserver/pending/blah where the client can check the status of this request. pending/blah returns a 200 code with "Status: pending" if the request is still pending, and a 303 code when it's done, with a final location for the result: http://fakeserver/finished/blah .
But what if the server crashes during the request processing? Should pending/blah return a 303 code, and then finished/blah returns a 404? How can I alert the client that the resource may be available at a location, but I'm not sure? Assume the requests are persistent, so that when the server reboots, it continues processing the request.
First of all I'll make the state of processed resource an internal field of this resource. This way you can avoid using strange endpoints like: /finished/blah/ or /pending/blah/ and instead of it introduce a single endpoint /resources/blah/ which will among other fields return the state it's currently in.
After changing architecture to the endpoint mentioned above if you ask for blah and server has crashed you can:
return 200 with pending status - client doesn't have necessarily to know about the crash
return 404, simple not found with and extra message that server has crashed.
return 500 and inform the client explicitly what the problem is.
Other useful codes may be also 409 or 503. Returning any 3XX is not a good idea IMO since no redirection applies here. Personally I'd go for 200 or 500(3).