Re: Length - any takers?

>> > When a 1.1 server knows it is talking to a 1.1 client
>> > how about requiring that only
>> >     Content-Length
>> >     Transfer-Encoding
>> >     Content-Type (Multipart types)
>> > be used to specify length and that closing the connection NOT be allowed
>> > for this case.
>. . .
>>The issue of allowing CGI scripts direct access to the client without having
>>the data 'validated' by something is a different issue. There are many ways
>>that servers can initiate CGI activity so if we pose the problem I am sure
>>that it will be solved.
>
>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).
>
>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.

This whole topic is something that the persistent connections subgroup has
tackled briefly. Having said that, most of the following represents my views
and not the views of the sub-group:

1) I dislike having some special # that means something. More C programs
have been brought into a buggy mess based on routines returning -1 for some
special value (And later -2 for some other special value), etc- I certainly
don't want our protocol spec to suffer the same fate.
2) There are situations where the server does not know the length of the
data it is transmitting when it starts sending it. Currently we have two
proposals for how this should work (Chunked encoding, multipart) and we are
trying to work our a consensus behind one of them so that we don't require
too many encoding types to be understood by clients.
3) There are also situations where the server sends an object with infinite
length. Some server pushes fit in this category. We must not rule this out.
4) With persistent connections, while there are situations where a client or
server will request that the persistent connection no longer be maintained,
often these connections are going to "time out". The only reasonable
solution for these circumstances is to close the connection, which implies
that clients & servers are going to have to support this anyway.
5) Connections get broken. So clients and servers need to deal with this anyway.

To summarize, I think its not a bad idea to suggest that people tag objects
with their size and with exact boundaries whenever possible. With persistent
connections these requirements WILL be more strict. However, closing the
connection will still retain an important role in the signaling of HTTP.
Alex Hopmann
ResNova Software, Inc.
hopmann@holonet.net

Received on Friday, 2 February 1996 14:10:26 UTC