Re: Content-Transfer-Encoding: packets for HTTP

Rick Troth ([email protected])
Sat, 15 Oct 94 02:25:14 CDT


[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, <[email protected]>, <[email protected]>, Houston, Texas, USA