This note has been fermenting in a borrowed lap-top for too long.
JR said:
<excerpt>
The desire to do multiple HEAD transactions is a powerful argument in
favor of holding off closing this issue. I'm pretty sure I'm going to
eventually want multiple HEADs, CHECKOUTs, PUTs, and DELETEs, at least.
..
</excerpt>
Wow. This tells me we really do want a more general "STAY ALIVE"
or "KEEP CONNECTION" model. I was feeling a little shy about putting
forth my own suggestion(s), but I've got "running code". All I need
is that "rough concensus" to meet the Dave Clark Criterion. ;-)
If you telnet to ua1vm.ua.edu port 80, you get a shell. No prompt,
but a shell nontheless. That's really what an HTTP server is.
This "shell" supports five commands: GET, POST, HELP, VERSION, and QUIT.
GET, POST, and QUIT all result in closing the connection, but HELP
and VERSION leave it open. (I don't think a machine would know when
it got to EOF; but these were intended for human consumption or even
just for play)
What I'd like to see is some new "command" for this shell that would
be the equivalent of a GET but that would not require closing the
connection to signal EOF. There are two possibilities: introduce some
SET verb to set any number of flags, the first one we implement being
STAY_ALIVE or KEEP_CONNECTION, or some such, -or- introduce some new
verb that means GET+STAY_ALIVE, say GET_ALIVE, or maybe GET_ALIFE?
The latter would immediately imply a companion POST_ALIVE verb.
If the verb were MGET, I'd prefer for it to have the same syntax as GET.
Since multiple bundles must be returned, I see no reason why they all
need be requested by a single MGET command, as some syntaxes put forth
would provide. Keeping the connection open is what we need, not a
reduction in the number of "commands" issued by the client.
MV said:
<excerpt>
I think this needs something a little more explicit by way of
specifying the boundaries between multiple responses ...
</excerpt>
I hope I'm not taking you totally out of context (because I think
you were talking about multi-session state here), but this is,
to me, the heart of the problem. (or the heart of the solution,
if you want to be more the optimist)
DK said:
<excerpt>
I would like to see a definition of Content-type-encoding: packet.
Specifically, which bytes are included in the byte count? CRLF's?
</excerpt>
I think we've already seen this a couple of times. The one I liked was
Dan Connolly's Content-Transfer-Encoding: packet, which is something like
4000 CR/LF
.. 4000 bytes of data (including CR/LFs) ...
123 CR/LF
.. 123 bytes more data ...
-1
.. signals EOF ...
In English, after the header (and after the blank line that follows it)
comes a number of octets on a line by itself. The CR/LF is part of this,
after which the receiver switches to "byte counting mode" in which it
stays until it has received the indicated number of octets. It probably
helps if these packets are on the order of 4K or 8K or so, though some
negotiation would help. If any such preferred block size prevails,
then the last packet will usually be something shorter. End-of-file
is indicated by a negative number. I recommend we NOT use zero for EOF
for the (unlikely) case when someone decides they need to send a few
zero length packets.
<excerpt>
Is the data uuencoded? Or are the bytes assumed to be binary data?
</excerpt>
There's no need for anything to be encoded, UU or B64 or any,
because we're on TCP and "packet" is itself a Content-Transfer-Encoding.
For the connection to remain open, there must of necessity be an
alternative EOF signal to what we've used up to now, closing the socket.
CTE "packet" (or something like it) gives us the required intermediate EOF.