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?

What about it?

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

Yes you certainly did.

> It's from section 4.2.

Middle of page 22, as a matter of fact.

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

Or put another way: it doesn't.

The paragraph you quote describes what a server MUST do in order to conform
to RFC 2616, but it doesn't explain what a client should do if the response
it receives from the server *doesn't* abide by those rules.

Clearly in Jim's case it's painfully obvious that the server responded with
multiple message-header fields with the same field-name that CAN'T be
combined into one "field-name: field-value" pair without changing the
semantics of the message.

And therein is the problem: what to do in such a situation? RFC 2616 doesn't
explain that.

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

You mean 8.1.2 and 8.1.2.1.

> How can interpret them differently?

It easy. I simply read what's written and interpret them to mean what they
actually mean, and not, like you, what you *want* them to mean.

Keep practicing, Nic. You'll eventually get the hang of it I'm sure.

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

Really? Huh. And here I thought it illustrated the issue perfectly. Silly
me.

> because that's a completly illegal response

Duh! So is responding with two separate Connection headers whose
field-values CAN'T be combined without changing the semantics of the
message, poindextor. That's illegal too, son, or didn't you realize that?
Please do try a little harder to keep up.

> (see section 4.2 again).

Section 4.2, for the umpteenth time, only explains the rule that *should* be
followed, NOT how one should react when said rule ISN'T followed. Clean your
glasses and read it again.

Several more times.

Slowly.

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

I assure it's true. I'm not one to lie.

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

You're sorely mistaken my friend. RFC 2616 is NOT clear about what to do if
one receives multiple "Connection:" headers with conflicting, semantically
different field-values. At best, it only states in section 4.2 that such a
situation is against the rules. It *doesn't*, however, explain how to react
when the rule is broken. NO document that I know of (that describes a given
transmission protocol in any detail) does, except possibly, as I said, in a
very broad sense.

NONE of them describe all the various ways the rules can be broken and now
to properly behave under such situations. That's not their purpose.

Their purpose is to simply describe the rules you're *supposed* to follow,
not how to react when those rules aren't followed (except, as I said, in a
very general way or possibly in a few commonly occurring specific cases).

But not matter how much you continue to say otherwise, the fact remains that
NO WHERE in RFC 2616 does it explain what to do when a client receives a
response with two conflicting Connection headers. NO WHERE.

And to claim otherwise is a lie 'cause it just ain't true.

> >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 RESPONSE AS A WHOLE IS NOT "PER SPEC", IDIOT! That's the whole fucking
point! (Christ you're slow.)

> The spec
> says that the connection MUST be closed if the connection header
> contains the close token.

What close token? I don't see any close token. All I see is a keep-alive
token. I'm magically closing my eyes and pretending that thing you're
calling a close token doesn't actually exist in exactly the same way you're
closing your eyes and pretending my keep-alive token doesn't exist.

Don't like that? Then wipe the crusties out of your eyes, look at the issue
with both eyes fully open and read what RFC 2616 actually *doesn't* say
about it.

That's right. What RFC 2616 *DOESN'T* say about the issue.

> What you are saying is that the header DOES NOT contain the "close"
> token - which IMHO is clearly wrong

What you are saying is that the header DOES NOT contain the "keep-alive"
token - which IMHO is clearly wrong.

> (because mainly of section 4.2 -

(because mainly you're dishonestly closing your eyes and magically
pretending that *other* Connection header with the keep-alive token on it
doesn't really exist.)

> where is your reference in the spec that states that you can do
> otherwise than what is in 4.2?)

What is it you think section 4.2 is telling one to do???

The only thing I see it telling us to do is to consider a response like the
one we got as being illegal/invalid.

I do NOT, however, see it telling us to magically close our eyes and pretend
the ambiguity that obviously exists in the response we received isn't really
there. Only *YOU'RE* doing that; RFC 2616 section 4.2 sure as hell isn't.

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

Such as??

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

I'm only reading what's there. No more. No less.


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

"Programming today is a race between
software engineers striving to build bigger
and better idiot-proof programs, and the
Universe trying to produce bigger and better
idiots.  So far, the Universe is winning."

                            -  Rich Cook

Received on Saturday, 2 September 2000 16:23:44 UTC