[5606] in www-talk@info.cern.ch
Re: Holding connections open: an immodest proposal
daemon@ATHENA.MIT.EDU (Dave Raggett)
Thu Sep 15 05:14:42 1994
Date: Thu, 15 Sep 1994 10:47:50 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: dsr@hplb.hpl.hp.com
From: Dave Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Marc VanHeyningen writes:
> The only real alternative anyone has suggested to Content-Length: is
> the MIME multipart boundary approach. It's not clear to me that
> that's better, and it sure as heck isn't backward-compatible.
Content-Length is fine where the server is reading from file it can stat,
but becomes problematic where the response is generated by say a program.
Another approach is to use a byte code escape mechanism, e.g.
a) replace all occurrences of \ by \\ and '\0' by \0
b) use '\0' not preceded by a \ to denote stream delimiter
Actually '\0' is a bad choice here since it crops up too frequently,
so one might want to use a more elaborate multibyte scheme. This approach
can be efficiently processed on the fly and wouldn't impose a heavy burden
unlike the multipart boundary scheme with its look ahead requirements.
We now introduce a new encoding name, say Content-Encoding: x-stream
which browsers can recognize and treat accordingly. Needless to say
the server only uses this encoding if the client states it can accept
it, perhaps this would be implied by the keep alive pragma.
The remaining issue is how servers determine stream delimiters in
client requests. The problem here, is what happens when a new client
talks to an old server - perhaps someone else can comment on this?
--
Best wishes,
Dave Raggett
-----------------------------------------------------------------------------
Hewlett Packard Laboratories email: dsr@hplb.hpl.hp.com
Filton Road tel: +44 272 228046
Stoke Gifford fax: +44 272 228003
Bristol BS12 6QZ
United Kingdom
