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