Can anyone provide an example of a simple HTTP server implemented using Netty, that supports persistent HTTP connections.
In other words, it won't close the connection until the client closes it, and can receive additional HTTP requests over the same connection?
This is exactly one of the things their sample http code demonstrates.
Related
I need to operate with a SOAP service from Erlang. SOAP implementation is not a subject, I have a problem with HTTP requests at a client side.
I use IBrowse as a HTTP client. This SOAP service uses a specific authorization mechanism, which relates an opened session to a client connection (socket). So, the client should use only one persistent connection to server (socket), and if it try to send a request via another socket (e.g., connection from pool) - authorization will fail.
I use IBrowse in this way:
Spawn connection process to server (ibrowse:spawn_worker_process/1)
Send request to server via spawned process with {max_sessions, 1} and {max_pipeline_size, 0}.
If I understand the docs right, this should use one socket for server connection with disabled pipelining, also, I use Connection: Keep-Alive header and HTTP version explicitly set to 1.0. But my connection is always closed after the response is received.
How can I use IBrowse (or another http-client) the way I described above?
I think you could that with hackney by reusing a connection.
Also gun is quite nice http client, easy to use, keeping connection, but with little less connection control.
I need some help with understanding how to write HTTP router, which recognizes HTTP header as routing criteria. I found the link https://github.com/cgbystrom/netty-tools/blob/master/src/main/java/se/cgbystrom/netty/http/router/RouterHandler.java which seems to do the routing itself. But now it is not clear, how to
connect to another HTTP server
send HTTP request
wait for HTTP response
forward the HTTP response to client
can somebody please give me some explanations?
http://static.netty.io/3.5/xref/org/jboss/netty/example/proxy/package-summary.html
the example of proxy server in Netty, essentially what I wanted
I am writing a HTTP proxy server and I noticed that many clients use the "Connection: Keep-Alive" header to keep a persistent connection. Is it possible that the client sends another HTTP request before the server processes the first?
For example, the client sends "GET / HTTP/1.1" but before the server has a chance to respond, the client sends "GET /favicon.ico HTTP/1.1". Is that possible? Or will the client pause for the response before sending the second request?
Also, when using a persistent connection, is it safe to assume all requests through that connection will have the same "Host: " header?
"Also, when using a persistent connection, is it safe to assume all requests through that connection will have the same "Host: " header?"
I don't think so, see HTTPbis P1, Section 2.2:
Recipients MUST consider every message in a connection in isolation; because HTTP is a stateless protocol, it cannot be assumed that two requests on the same connection are from the same client or share any other common attributes. In particular, intermediaries might mix requests from different clients into a single server connection. Note that some existing HTTP extensions (e.g., [RFC4559]) violate this requirement, thereby potentially causing interoperability and security problems.
Yes, it is possible for the client to pipeline requests. (See http://en.wikipedia.org/wiki/HTTP_pipelining).
Turning your last question around... it would not be safe for a client to assume that requests to multiple hosts would be served by a single pipeline. There may be no specs that directly address your question on the Host: header, but it's a safe bet they'll be the same.
Regarding the first question:
Is it possible that the client sends another HTTP request before the server processes the first?
I believe that yes, it can be possible (perhaps I am wrong, I remembered having read that a couple of years ago; the definitive answer is in the HTTP protocol specifications). But I don't understand why you are asking. Also, the client can open several TCP connections at once to the same HTTP server. And of course you have many simultaneous clients.
About the second question
Also, when using a persistent connection, is it safe to assume all requests through that connection will have the same "Host: " header?
I believe it is usually the case, but I won't assume that to be certain. I could imagine that some clever HTTP clients, recognizing that two URL with different Host: headers share the same IP, could re-use the same connection.
But I don't understand why you are asking. Persistent HTTP connections have been invented to minimize the TCP connections which are costly, and the two questions you are asking are an extreme point on that. Perhaps few HTTP clients are doing what you describe today.
And you should be strict on what you send (w.r.t. standard conformance), but flexible on what you accept receiving.
Should I use Timeouts in a HTTP Server implementation?
E.g. if I get a request and create a HTTP Connection to listen to requests with a separate Thread, should this thread use timeouts?
Currently I don't use Timeouts in Debug Code, only in Production code, as to find the lockups in the Server.
As long as you adheres the HTTP specification, I don't forsee problems.
From this article on Wikipedia:
Keepalive messages were not officially
supported in HTTP 1.0. In HTTP 1.1 all
connections are considered persistent,
unless declared otherwise.
Does this mean that using this
mechanism I can actually simulate a
TCP socket connection?
Using this can I make a Server
"push" data to a client?
Are all HTTP connections, even the
one I am using to connect to Stack
Overflow "HTTP persistent"?
Does the COMET technology of
server push use this mechanism of
HTTP persistent connection to push
data to clients?
Does this mean that using this mechanism I can actually simulate a
TCP socket connection?
Not really, sockets have MANY more features and flexibility.
Using this can I make a Server "push" data to a client?
Not directly, it's still a request/response protocol; the persistent connection just means the client can use the same underlying socket to send multiple requests and receive the respective responses.
Are all HTTP connections, even the one I am using to connect to Stack
Overflow "HTTP persistent"?
Unless your browser (or a peculiar server) says otherwise, yes.
Does the COMET technology of server push use this mechanism of HTTP
persistent connection to push data to
clients?
Kinda (for streaming, at least), but with a lot of whipped cream on top. There are other Comet implementation approaches, such as hidden iframes and AJAX long polling, that may not require persistent connections (which give some firewalls &c the fits anyway;-).
Actually, the HTTP server can "push" data to a connected http client without the client requesting it. See "HTTP server push" at http://en.wikipedia.org/wiki/Push_technology. However it does seem to be commonly implemented.