Comments on revision 03 of " Hypertext Transfer Protocol -- HTTP/1.1 "

As the primary author of a free http/1.0+ web server (for OS/2)
with a goal of keeping the product reasonably up to date,
I have been sporadically following the http 1.1 drafts, related RFC's, 
and the HTTP-WG mailing list.  At the recommendation of several
working group members, I have read the rev. 03 of the draft; with an
eye toward what an implementor might have problems with. From
that viewpoint, consider the following comments:

) The importance of chunked coding -- add a note to 19.6

  The default of persistent connections has major  implications for the
  delivery of dynamic  documents,especially when compared to  http 
   1.0. Although this is discussed in the draft, I  believe that it
    should be strongly emphasiszd. In  particular, a paragraph should be
    added to 19.6.1 (or  19.6.2). For example:

   "Given that persistent connections are the http/1.1  default, special
   care must be taken when  dynamically generating output, especially   
   when  earlier portions of content are sent to the client  as they are
   generated (say, to prevent automatic or  human time-outs). In this
   (and other) cases, there  may  be no way of knowing the final length
    of   content, hence a content-length header can not be  added.
    Hence, either the connection must be closed after transmittal of
    content, or chunked coding  must be used. 

II) "Chunked" in the TE header -- clarify  description

  It is somewhat odd that:
    i) Given that (section 3.6.1, and reiterated in 
        step 3 of 14.39)
        "All HTTP/1.1 applications MUST be able to   recieve and
         decode the "chunked" transfer    coding..."
   ii) Also in (section 3.6.1, and reiterated in 14.39 and
       14.40)
       "A server using chunked transfer-coding in a    response MUST
        NOT use the trailer for other   header fields than ... unless the
       "chunked"    transfer-coding is present ..in the TE field).

     Since 1.1 apps (such as http/1.1 servers) must  understand     
     "chunked", then point ii seems to mean  (informally):
      "the use of "chunked" in the TE field tells an http/1.1 server that
      header fields other then Content-MD5   and Authentication-Info
     (and Content-Length)   may be included in the trailer".

    Assuming I'm not misreading, it might be useful to 
    include this comment (or an appropriately formal
    version).

   
III) Pipelining -- does order of execution matter?

  Section 8.1.2.2 states:
    "A server MUST send it's responses to those  requests in the  same
   order that the request were recieved."

  Does this imply that there should be no parallelism when  processing
   piplined requests: that request A should  be completely answered
  before request B is   considered. Or, is parallel resolution of these
  requests permitted, so long as order of return is   serial (and follows
   the order of requests).
  

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? 


V) Minor points
  
  * It might be useful to add in section 10.3.7
       "The difference between 302 and 307 is that 307 insures  (for
        http 1.1 clients) that a redirection occurs without a change in
        method."

  *In 13.1.1, point 2, it is written:
       "In the default case, this means it meets the least restrictive
        freshness requirement..."
   Shouldn't that be "most restrictive".


Daniel Hellerstein
danielH@econ.ag.gov
http://rpbcam.econ.ag.gov/srehttp

Received on Tuesday, 24 March 1998 06:40:46 UTC