Re: GET, POST, Keep-Alive, Content-Length and Proxy

The appended message is from a mailing list for Jeeves, Sun's Java
web server. I thought it was of interest to the Squid community too.
The problem under discussion is how to let Applets and Servlets set up
a semi-permanent two-way communication channel *through* an HTTP proxy.
The basic idea he's proposing is that POST requests that are missing
a Content-Length header should be treated as uncachable arbitrary-length
two-way connections, and the proxy should just forward data until EOF.

---
Jef
------- Forwarded Message
Date: Thu, 26 Sep 1996 11:14:06 +0100
From: "Bernhard A. M. Seefeld" <seefeld@RELOG.CH>
Subject: GET, POST, Keep-Alive, Content-Length and Proxy
To: Multiple recipients of list JEEVES-INTEREST
    <JEEVES-INTEREST@JAVASOFT.COM>
Hi ..
I have a problem with your "Extension" of the GET method, namely
the possibility of sending extra data. Specifically, the problem
arises with proxies not knowing the custom protocol (like in the
ChatServer servlet) and wanting to support Keep-Alive. Most proxies
probably wouldn't propagate any extra data with GET anyway. And with
POST, only extradata of a known size (i.e. Content-Length is specified)
would be handed along.
Now let's imagine that the next versions of the proxies wanted to
support this feature (which would be nice, as this would allow
applet<->serv(er|let) communication through strict firewalls without
having the poor firewall administrator figure out and enable a
specific portnumber for yet another onlinegame...). This implementation
is particulary difficult in conjuction with Keep-Alive (the proxy
has to know when the extra data is finished and that the next
line sent by the client is in fact a new request (which you also want
to cache)). In general, Keep-Alive and extradata is not possible through
a proxy (note, that this would still be possible in a direct connection
as the custom protocol could include some kind of End-Of-Communication
mark).
BUT: Why extend GET at all? Isn't POST the better method anyway? POST
has been invented specifically to send extra data to the server.
Currently all implementations require the Content-Length: Header in
the request. The only difference in the implementation (of the proxy)
would be to allow POST requests without Content-Length: which would
result in disabling (i.e. not sending any Headers concering) Keep-Alive
and to steadily copy the clientside input to the serverside output
(from the proxy's point of view). (The proxy should do that in every
case (also with Content-Length) anyway, in order to support efficient
<INPUT TYPE=file ..> support with long files)
Genereally, the only way to give a GET some extrainformation on the
way is to use headers. POST is IMHO better suited for the purpose
of "within-request-communication".
Of course, this doesn't mean, that the support of sending information
with a GET should be disabled in Jeeves. People should just be
encouraged to use POST instead of GET.
Why am I writing all this? In "sun.server.http.HttpInputStream.html"
you write:
   This class also includes additional support for automatically
   closing the connection when input becomes idle, in order to support
   keep-alive.
This is probably what causes the connectioncloses in a conversion
with the ChatServer servlet. Unfortunately, this makes the use of
this extrachannel unusable (The network can always hold still for a
too long time, so that regular "Keep-this-Connection-Alive-because-I-am-
still-there" packets could arrive too late). Disabling this timeout
feature (or extending the timeout by a very high amount) in case of
POST method with unspecified Content-Length would solve this problem.
Generally I am not quite sure why you need that timeout
_to_support_keep-alive_. Keep-Alive doesn't work anyway, if the
reply doesn't contain any Content-Length Header. And if it does, the
timeout should be activated _after_ sending the data out. Am I missing
something?
                Sincerly,
                    Bernhard
--
My opinion, my typos.
------- End of Forwarded Message