Comments on draft HTTP/1.1 spec, v3
Arthur P. Goldberg (artg@cs.nyu.edu)
Wed, 29 Apr 1998 22:23:36 +0100 (BST)
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