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

Are you saying then, Nic, that if someone requests to the maitre d' of a
restaurant that they wish to be seated in the smoking section, and
immediately after stating that wish, turns around and changes their mind by
requesting to be seated in the non-smoking section instead, that you
personally feel they should be seated in the smoking section anyway because
that's what they requested first? :)

"Fish" (David B. Trout)
   fish@infidels.org

> -----Original Message-----
> From: Nic Ferrier [mailto:nferrier@tapsellferrier.co.uk]
> Sent: Saturday, September 02, 2000 5:01 AM
> To: fish@infidels.org; www-talk@w3.org
> Subject: re: Connection: close (was: Re: Msg header)
>
>
> >>> "Fish" <fish@infidels.org> 02-Sep-00 5:08:32 AM >>
> >I respectfully disagree.
> >While RFC 2616 doesn't mention specifically how to
> >handle such a situation, it does mention that the order
> >of individual field values for a given header *is* significant.
> >Thus I would think that common sense would prevail in
> >such a situation and the each subsequent new occurrence
> >of given field value would override any previous value so in
> >the example Jim provided, "keepalive" would override
> > (i.e. replace) the previously supplied "close" value.
>
> Where are you getting that from. I can only see this in RFC2616
> section 4.2:
>
> "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, by appending each subsequent field-value to the first, each
> separated by a comma. The order in which header fields with the same
> field-name are received is therefore significant to the
> interpretation of the combined field value, and thus a proxy MUST
> NOT
> change the order of these field values when a message is forwarded."
>
> The important bit here is the "it MUST be possible to combine the
> multiple header fields" which is contravened by sending two opposing
> header fields.
>
> Anyway, my reading of RFC2616 section 8.1.2 and 8.1.2.1 is that if
> the "close" token is present for the "Connection" header then the
> connection MUSR be closed.
>
> In the example given the "close" token is present, so the
> "Connection" *must* be closed.
>
>
> Nic
>

Received on Saturday, 2 September 2000 08:56:42 UTC