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

>RFC 2616 says nothing about how to handle this 
>situation, Nic, and you know it. 

What about this?

"Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of
the
message"

I quoted that to you before. It's from section 4.2. It rather blows
away your point about making decisions about header content based on
the last value found (and the reference to that policy you have not
produced - I personally can't find it).


>You're reading more into than what is really there, 
>my friend. :)

I don't think so - section 4.2 and 8.2.1 are quite clear to me. 

How can interpret them differently?


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

That's a tricky one because that's a completly illegal response (see
section 4.2 again).


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

No. RFC2616 is very clear about how and when a client, server or
proxy should behave with bad responses. Particularly HTTP/1.1
responses.


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

Yes - I did understand your point. But that's not per spec. The spec
says that the connection MUST be closed if the connection header
contains the close token. 

What you are saying is that the header DOES NOT contain the "close"
token - which IMHO is clearly wrong (because mainly of section 4.2 -
where is your reference in the spec that states that you can do
otherwise than what is in 4.2?)


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

Yes... and there are specified ways for the server to resend that
response if an when it recieves a broken pipe.

But that's not at issue - you are reading the spec wrong.


Nic

Received on Saturday, 2 September 2000 13:20:48 UTC