I am creating a Netty Client which sends HTTP request to POST data to server.To increase the performance what i did was using Keep alive Http request(i know that in HTTP 1.1 all requests are keep alive by default, so i am making sure that Connection header is not set to close while sending the Http request) so that it uses the same channel to send the Http Request. Now when i send the Http request to the correct URL,i.e. if i get HttpResponse Status OK in return from server, i am able to send the next Http Request properly but when i send the Http Request for which i get BAD REQUEST or SERVICE UNAVAILABLE or something other than OK then i am unable to send the next request that is the channel future f.success() returned after calling channel.write(request) is false. I am unable to understand why it happens. I have followed the same model of coding as done in HttpSnoopClient example given in netty,
except i have removed the connection:close header & even the client handler is the same as that given in snoop client, also i have am instantiating the bootstrap only once at the starting
I tried getting channelFuture f.cause().getMessage() but it was null it seems
Related
I’m writing small http server and try to understand timeout issues.
RFC7230 don’t give an answer for the question what are conditions that forces server to send timeout (408 Request timeout). Should it be sent when client sends request too long? Or if nothing was sent in opened connection for some time? What the logic should be? Is there any standard or behavioral model?
The whole process would be
server wait for a request -> read request header -> read request body -> prepare response header -> prepare response body
So if the request take to long Ex: 30 seconds, then server will return a response header with code 408 Request timeout
The next case is when server can read whole request header and body and try to process that request but can not complete in an amount of time then it will return 504 Gateway Timeout or 503 Service Unavailable.
It will depend of each situation. But the rule is always use 4xx for request errors and 5xx for server errors
The short explaination for thoose http code is listed here: HTTP response status codes
I was playing around my redis server and tried to hit with the browser. Redis detected it as a Cross Protocol Scripting attack and returned an error in the response's payload. However, when I checked the window's console, it turned out that the request was returned without a status code. So, in such cases what status code should a client assume?
There is no such thing as a response without a status code. Every HTTP response has one, and if you didn't get one it means:
You weren't talking to a HTTP server.
The HTTP server did something it shouldn't.
In each case I would expect your HTTP client to throw some kind of exception but not return a Http Response object.
I'm using QNetworkAccessManager to send HTTP GET/POST requests. Sometimes I would like to send a request immediately before closing the application. There is no need for me to wait for the server reply. But when I do that, the request doesn't seem to get through.
After calling get(), how can I make sure that the request was sent before destroying the application?
Can the HTTP client send a request while receiving the HTTP response?
For example, a client sends HTTP request A to server. Then, the server starts to send HTTP response. Before the client finish to receive HTTP response A, the client sends additional request B. Can it be possible? or Does it follow the HTTP RFC?
I think that above scenario is different from the pipelining. What I know about the pipelining is the scenario that client send multiple request A,B,C then the server response A,B,C consecutively. However, in the above scenario, request B is issued while the processing the response A.
Thank you
With the same connection object you must read the whole response before you can send a new request to the server, because response provides access to the request headers, return type and the entity body, If you send new request before fully reading response, client may get confused with mismatched responses.
Again it totally depends upon client library you using. Library could allow asynchronous requests.
There are concepts like
AsyncTask in android, promis in Angularjs etc.
allow asynchronous request.
HTTP Protocol: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#header.expect
A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message
If the server wish to close the connection it will include "Connection: close" in his response. But how can it tell the client it wish to continue reading and discarding the body ? I don't know any header to do that.
And if it receive the body and discard it, this doesnt mean that "100-Continue" is useless ? That's the whole point of "100-Continue", not sending the body if it will be rejected anyway.
When the server sends its final reply, it has finished processing the request. If the server sends that reply while the client is still sending its data, the client should stop sending, and then the presense of an HTTP keep-alive (an explicit Connection: keep-alive header in an HTTP 1.0 reply, or a missing Connection: close header in an HTTP 1.1 reply) is the server's indication that it will be discarding any remaining data that is sent, since it needs to clear the socket of pending data before it can receive a new request on the same connection.
The 100-Continue is not useless. Think of what happens when the server sends 100 to let the client start sending, then later errors and decides to stop receiving and send a final reply reporting the error. The server did not know at the start of the request that it was going to error.