> 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