|Subject:||Re: HTTPServer or just a TCPServer|
|Posted by:||Remy Lebeau (Indy Team) (firstname.lastname@example.org)|
|Date:||Tue, 13 Mar 2007|
"Rene Tschaggelar" <no…@none.net> wrote in message
> Upon a closer look at the subject I found the
> HTTPServer to be a ill suited construct.
Why do you think that?
> For some historic reasons, the HTTP commands are
> sent as TCP commands, but contrary to the usual
> TCP interactions, HTTP is connectionless.
Not really. HTTP v1.1, which is very commonly used now, added
additional features to the state of connections from earlier versions.
In v1.1, the default behavior now is to keep the connection open after
sending a response, unless the client explicitally asks for the
connection to close, or the server needs to close it for its own
reasons. This way, clients can send multiple requests over a single
connection, which is much faster and more efficient than creating a
new connection per request. This was possible in HTTP v1.0, but the
client had to explicitally ask for it, and the server had to agree to
it. Now it is a requirement for conforming implementations on both
ends to support this behavior by default.
> I should route HTTP commands from a browser to
> a device connected to the serial port. The serial
> port is connected as nonblocking.
> The HTTP server is blocking.
So what? There is nothing stopping you from using a blocking server
in front of a non-blocking device.
> This means to connect the two, I'll need a separate thread.
So? You can have a persistent object talking to the serial port on
one end, and caching and updating the data that the HTTP server
accesses on the other end. What is the problem?
> Or would the whole become simpler If I started
> with a TCP Server ?
TIdHTTPServer is a TCP server, so you are not gaining anything by
strippiong off the HTTP layer.
HTTPServer or just a TCPServer posted by Rene Tschaggelar on Wed, 14 Mar 2007