- From: J.P. Martin-Flatin <martin-flatin@epfl.ch>
- Date: Sun, 14 Jun 1998 20:10:26 +0200
- To: http-wg@cuckoo.hpl.hp.com
- Cc: martin-flatin@epfl.ch
I was wondering whether persistent HTTP/1.1 connections could be used as bi-directional sockets, where both the client and the server can send data asynchronously to the other side. In other words: * Can an HTTP server send data asynchronously to an HTTP client (response without request)? * Can an HTTP server send multiple responses to an HTTP client, without the client knowing in advance how many responses it will receive, or how long it will take for the server to send all its responses? This would have allowed all socket-based client/server applications to tunnel traffic over HTTP, and therefore go across a firewall easily. Implicitly, section 1.4 answers no to all these questions. I think this should be stated explicitly (HTTP is clearly not primarily geared towards that, but more and more people are using HTTP outside the Web context). Here is the first paragraph of section 1.4: The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. The relationship between HTTP and MIME is described in appendix 19.4. I suggest to add the following right after: The server must not send more than one response message to a given request message (that is, multiple responses are forbidden). The server must not send unsolicited messages to a client: all messages sent by the server are responses to requests previously issued by this client. Jean-Philippe Martin-Flatin
Received on Sunday, 14 June 1998 11:13:10 UTC