W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: Comments on draft HTTP/1.1 spec, v3

From: Dave Kristol <dmk@bell-labs.com>
Date: Thu, 30 Apr 1998 10:16:12 -0400
Message-Id: <354887AC.1F8D@bell-labs.com>
To: artg@cs.nyu.edu
Cc: http-wg@cuckoo.hpl.hp.com, adam.donahue@nyu.edu
Arthur P. Goldberg wrote:
> 
> Hello working group
> 
> I sent this Sun, 26 Apr but received no reply:

The working group archive does not show the earlier message, as far as I
can see.

> 
> 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.

That's great!

> 
> 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.

Actually, no.  The most recent draft,
draft-ietf-http-v11-spec-rev-03.txt (and earlier ones, too), is quite
clear on this.  In 14.25 If-Modified-Since the spec. says, "If the
request would normally result in anything other than a 200 (OK) status,
or if the passed If-Modified-Since date is invalid, the response is
exactly the same as for a normal GET."  Your example is the "invalid
date" case.

> Should the response, containing a 400 bad request error,
> return the error chunked and then close the connection?  In

TE is a request header that provides advice from the client to the
server.  I think you meant Transfer-Encoding: chunked.

The server may send a chunked (error) response, and it need not close
the connection.

> 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.")

I think that's just trying to draw a parallel between HTTP and
object-oriented systems.  HTTP methods are similar to object methods,
and the request headers are similar to the parameters one supplies in a
method invocation.

> "The semantics of all valid headers SHOULD be applied."

I'm not sure what, if anything, that improves.  I think it's already
implicit throughout the spec.

> 
> 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

Yes, whenever possible.  It's considered very important.

> 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."

Again, I think that's redundant.  If a server keeps a connection open,
it does so presumably because it's prepared to accept further requests. 
One reason for closing a connection, in fact, is that an error forces
the server to lose sync with the input stream.

> 
> 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


I think your suggestion is redundant by harmless.  In general if there's
an (error) response code for condition X, there's the implication that
if X happens, then the server will send an X response.  Timeout is but
one example.

> 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'.

Actually that phrase meant something quite different.  (The paragraph
mentions both clients and servers, and a client can't send a 408
message.)  The phrase means that the agent should try to close its
connection in a way that lets any packets in transit reach their
destination.  It's worded elliptically to avoid making it too
TCP-centric, but what it really wants to say is "avoid forcing a TCP
reset on the connection prematurely, because the receiving end will miss
bytes in transit".  Those bytes could even include a 408 Request Timeout
message.

Dave Kristol
Received on Thursday, 30 April 1998 07:40:29 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:15 EDT