W3C home > Mailing lists > Public > www-talk@w3.org > September to October 2000

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

From: Fish <fish@infidels.org>
Date: Sat, 2 Sep 2000 14:01:43 -0700
To: <www-talk@w3.org>
Message-ID: <000301c01520$ffc1c680$0200a8c0@proteva.family>
Another reason why I think Nic has had too much to drink:

> Another reason why the UA should pay more attention to the "close"
> value of the Connection header than the "keep-alive" value is that if
> the client keeps the persitent connection open there will be a delay
> whilst the server waits for timeout before bringing the connection
> down.

So?

> Even if the server *does* mean to keep the connection alive it can
> always resend responses.

How? The connection's been closed.

> But if the UA keeps the connection open the user is left waiting for
> the timeout period.

So?

> That's not very user friendly...

Please explain how a user is *negatively* impacted by a client keeping a
persistent connection open to a server.

> it was also what
> prompted Jim to ask the question in the first place (so in his
> situation it would obviously have been the "correct" thing to do).

Nope. But thanks for playing.

> One more reason for closing the connection in Jims case is that
> "Connection: keep-alive" is not a defined part of the HTTP/1.1 spec.

So?

> The token keep-alive has no meaning. See section 14.10 of RFC2616.

Wrong. See section 19.7.1 of RFC 2068.

Also see read RFC 2616 again. ALL of it this time, including section 19.6
which you seem to have missed.

> And the last reason I can think of is that the "Connection:
> keep-alive" header:token value is the system used by some HTTP/1.0
> servers which presumes that the connection will be closed unless
> otherwise specified.
>
> It could be that what is being talked to by Jim is an HTTP/1.0
> webserver connected to an HTTP/1.1 servlet engine (or possibly vice
> versa).

Huh? You're making this up as you go, aren't you?

> Imagine it:

I was right: you *are* making this shit up.

> the servlet engine is behaving with what it understands
> of it's protocol - it sets the response to HTTP/1.1 and puts in the
> "Connection: close" header because it no longer needs the connection.
> But then the slightly stupid webserver takes over and adds it's own
> concept of the "Connection" header - thus confusion.

Stay off the booze, Nic. It can't be good for your liver to be drinking that
much.

> Remember that 1.0 relied upon the client to close the connection if
> it wished, essentially saying this:
>   If there is a UA at the end of this connection who
>   understands this persistence protocol and wishes
>   the connection to remain open it will hold it open,
>   otherwise it'll get closed down
>
> Therefore, thinking pragmatically,  HTTP/1.1 UAs (and proxies on the
> server side) should always prioritize a "close" higher than anything
> else.

Remember that "section 8.1.2 and 8.1.2.1" crap you were blabbering about?
Well put down bottle of M.D., focus those bloodshot eyes of yours and try
scrolling up just a tad. If you're not too drunk you might notice section
8.1.1 explains why it was decided HTTP/1.1 would implement persistent
connections as the default.

> Hic! (burp) 'scuse me.

You're excused.

Now go lie down and sleep it off so when you wake up, these RFC thingies
won't seem so "tricky" to you.


     "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 17:01:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT