Comments on revision 03 of " Hypertext Transfer Protocol --

IV.i - This really means, graceful socket close to avoid TCP reset.
IV.ii - no, there is (somewhere) a phrase I asked for basically saying
        that in any case the implementation is free to defend itself
        from attacks. (and this to IV.i also).
        The real problem that this item addresses is that the status
        code is sent up-front, and if there is no content-length, there
        is no good way for the client to know if the object was
        truncated (or any indication of why).  This is especially a
        problem for FTP proxies, who may not themselves know the size
        of the object unless they parse a directory listing from the
        server.  If one is chunking the output, you have a trailer, but
        no currently defined way to indicate there that an error
        occured.  Your only choice is to abort the connection.

I for one, would really like to see the ability to add a trailer to
the end of any response indicating status.

** Reply to note from Daniel Hellerstein <danielh@MAILBOX.ECON.AG.GOV>
Mon, 23 Mar 1998 11:58:27 -0500 >   
<snip>
>   
> IV) Closing connections 
>   
>     Section 8.1.4 states:
>   
>     i) "When a client or server wishes to time-out, it   SHOULD issue a
>        graceful close on the transport   connection".
>   
>     Does this imply some sort of action at the http level? 
>     That is, should a 4xx (or 5xx) response be sent? 
>   
>     And what if this time out occurs in the middle of a  response;
>      say,the early portion of a dynamic  resource is sent, and then an
>      unexpectedly long  delay occurs whilst resolving the remainder of     
>      this  dynamic resource (thus, a new response line &    headers can
>      not be sent).
>   
>     
>     ii) "Servers SHOULD NOT close a connection in the   middle of
>        transmitting a  response,  unless a network or client failure is 
>        suspected".
>   
>     Does that disallow a "total time per connection" server setting? 
>     Even if an otherwise legitimate request is taking hours to resolve? 
>   
<snip>
>   
> Daniel Hellerstein
> danielH@econ.ag.gov
> http://rpbcam.econ.ag.gov/srehttp
>   
> 
 

Richard L. Gray
will code for chocolate