RE: Connection: close (was: Re: Msg header)

> No - I'm saying that when you write a webserver you should carefully
> read the latest revision of RFC2616.
>
> /8->

I have.

Several times.

Quite closely.

Hell, I *had* to in order to be able to develop the HTTP/1.1 compliant proxy
server I wrote.

RFC 2616 says nothing about how to handle this situation, Nic, and you know
it. You're reading more into than what is really there, my friend. :)

You're interpreting it the way *you* see, but not everyone sees it that way.

What if it wasn't the Connection header that was duplicated? What if the
response had been:

   HTTP/1.1 200 OK
   Server: Netscape-Enterprise/4.0
   Date: Wed, 30 Aug 2000 19:02:26 GMT
   Content-length: 148
   Content-length: 841
   Content-type: image/gif
   Content-type: text/html
   Connection: keep-alive

Then what? Which value would you use? 148 or 841? "image/gif" or
"text/html"?

Prudence demands a dose of common sense in these type of situations, and
common sense tells me each new value for a one you already have overlays the
old one. Thus IMO the content-length/type that should be used is 841 and
"text/html" respectively.

The same holds true in Jim's situation IMHO: even though close was indeed
specified in the first Connection header, the subsequent keep-alive value
essentially
negated/nullified/overlayed/overrode/whatever-terminology-you-prefer'ed it
such that it the response should be treated as if the Connection: close had
NOT been specified.

Thus, keep the connection open and let the server close it when it's good
any ready since *it's* the one in charge of the connection anyway. It
*could* have another response to send back on that connection afterall,
since it *did* say "Connection: keep-alive". :)

At least that's my 2 cents.

Received on Saturday, 2 September 2000 12:34:27 UTC