Comments on draft HTTP/1.1 spec, v3

Hello working group

I sent this Sun, 26 Apr but received no reply:


Ninety computer science graduate students of mine are 
implementing partial HTTP/1.1 servers.  They have been 
reading and analyzing the draft specification, versions 2 
and 3, very carefully.  Overall the specification is 
very strong.  however, we find a slight amount of confusion and 
ambiguity, and would like to share our comments.

5.3
ambiguity on application of request header semantics.
Suppose a request contains an error.  Should all semantics 
of all correct headers in the request be applied?  For 
example, consider

  HEAD /index.html HTTP/1.1
  Host: 128.122.238.94:9999
  Connection: close
  TE: chunked
  If-Modified_since: foo
 
"foo" is an invalid value for If-Modified, and therefore the 
one and only correct response to this message will be 400. 
Should the response, containing a 400 bad request error, 
return the error chunked and then close the connection?  In 
my view the answer is yes, and we should consider adding the 
following sentence to the end of the first paragraph in 
section 5.3.  (I do not fully understand the meaning of 
"semantics equal to the parameters on a programming language 
method invocation.")
"The semantics of all valid headers SHOULD be applied."  

8.1.4
in general, we're confused whether the specification wants 
servers to try to maintain persistent connections when 
errors occur.  I believe that performance considerations 
make it desirable for servers to maintain persistent 
connections whenever possible. reasoning that a persistent 
connection is simply a sequence of one-request connections, 
it makes sense to keep using the persistent one, just as an 
HTTP client keeps making requests following an error 
response.  Inserting the following sentence as the sixth 
paragraph in 8.1.4 would clarify this point.  "If a server 
detects an error (status 4xx) in a client request on a 
persistent connection, then the server SHOULD try to parse 
and respond to subsequent requests on the connection."

10.4.9
We do not understand the semantics of the request time-out 
408 status code.  We have assumed a meaning which would be 
clarified by inserting the following sentence after the 
first sentence in section 10.4.9.  "When a server times-out 
a connection it SHOULD send a response with a request 
time-out status before closing the connection."  It would 
also be helpful to clarify the meaning of "graceful 
close" in paragraph 2 of 8.1.4 by inserting the phrase "by 
sending a 408 message" following the word 'close'.

We hope these comments are helpful.
Thank you


-- 
Arthur P. Goldberg
Clinical Associate Professor of Computer Science
artg@cs.nyu.edu       http://www.cs.nyu.edu/cs/faculty/artg
FEB and MARCH, 1998: excuse my brief emails, RSI's limiting my typing
715 Broadway, Room 711, Computer Science Department
Courant Institute of Mathematical Science
New York University
New York, NY 10003-6806
212 998-3014   fax 995-4123

Received on Thursday, 30 April 1998 05:28:51 UTC