[6421] in www-talk@info.cern.ch
Re: Content-Transfer-Encoding: packets for HTTP
daemon@ATHENA.MIT.EDU (Rick Troth)
Sun Oct 30 16:37:37 1994
Date: Sun, 30 Oct 1994 22:27:47 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: TROTH@UA1VM.UA.EDU
From: Rick Troth <TROTH@UA1VM.UA.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
[www0.cern.ch seems to occasionally dislike ua1vm.ua.edu]
>The returned data might look like:
>
> 0200 document follows
> Content-Type: application/octet-stream
> Content-Transfer-Encoding: packet
>
> 4000
> ...4000 bytes of stuff...
> 1745
> ...1745 bytes of styff...
> 0
>
>Then the connection would be available for another transaction.
I like this. I'm not entirely happy with aggregate's use of a
"dot on a line by itself", but there is certainly precedent for that.
But CTE packet could work.
I attacked the very same problem with the SIFT/UFT protocol.
This is a protocol for sending files, kind-of a combination of LPR/LPD,
SMTP, and FTP. (there are reasons why I wanted to invent another wheel)
I don't remember if RFC 1440 was up to this level or not. SIFT has
changed for the better since they put out 1440. It goes something like
... other session verbs/commands, like "NAME", "USER", "TYPE" ...
DATA 4000
...4000 bytes of stuff...
DATA 1745
...1745 bytes of stuff...
EOF
... other verbs/commands, ending with "QUIT" ...
... (you could have an "ABORT" if there's trouble) ...
The problem is that you have to "switch modes" from CR/LF lines
to byte counting. This is quite significant if your O/S isn't byte
oriented. I did the original work on VM (CMS) which is heavily record
oriented. All that mode switching is why you've heard me whining about
Content-Length -vs- something like a line count, though I don't really
see any other way to do it over TCP unless you want the overhead and risk
of "boundary" pattern matching.
So ... you get my vote, Dan.
>Dan
--
Rick Troth, <rmtroth@aol.com>, <troth@ua1vm.ua.edu>, Houston, Texas, USA
