Re: Length - any takers?

> I'm not clear here on when you say "...Content-Type...be used to specify
> length". What if a CGI script *can't* know the length, such as in a "server
> push" situation (which uses multipart types and just keeps sending part
> after part until the user closes the connection).

Unless I'm really confused, the idea is to provide a more reliable
mechanism for a client to find the end of an object than provided by
the server closing the connection. Content-Length: does this directly.
However, there are situations where the finding the content length in
advance is expensive, if not impossible. The other two headers fields
deal with that case, by providing an "end-of-object" indicator for the
different situations.

For example, if you have a multipart objects, then the size of each
part is determined seperately and presumably reliably. You reach the
end of the object when you get the encapsulation boundary following
the last part. That there is no "last part" in a server push situation
doesn't change this.

In the case of dynamic objects which have an unknown initial length,
you use the transfer-encoding of "chunk", which allows you to send an
arbitrary number of non-zero length chunks, and you reach the end when
you get a zero-length chunk.

> As to Larry's suggestion of "strongly recommended", I have a
> not-well-thought-out idea: allow "Content-Length: -1" to mean "I definitely
> don't (or can't) know the content length and I might use disconnect
> instead". This lets 1.1-aware clients know more than just "the server
> thinks it knows the length" and to be more prepared for disconnects.

While you're at it, make Content-Length default to "-1" so we can just
leave it out.

	<mike

Received on Friday, 2 February 1996 11:23:17 UTC