I'm just saying this so I don't get lynched by people who write servers OR
by people who write browsers, but the problem being discussed on the W3C
list was disagreement between server and browser, after server operators
realized it could be solved on the server side by turning off persistent
connections.
I didn't mean to imply that the servers, or for that matter the clients,
were the ones at fault (in any given case where they disagree, at least one
of them will be wrong, if the spec is unambiguous, but I wasn't trying to
figure out which).
On this subject, I'm reminded of the early days of deployment of
digital-trunk-capable central office switches. When you deploy the first
one, all the switches they are connected to are still only capable of
handling analog trunks, so you configure all the trunks that way; when
someone deploys the second one, they just match the trunking of the analog
central office switch that's being replaced - which included analog trunks
to the first central office, and the two digital central office switches
happily do digital-to-analog-to-digital conversions until someone notices
they don't have to do ANY of this!
So I'm wondering, if all the servers get fixed, and all the clients get
fixed, will we be running persistent connections THEN?
This thread is getting off-topic for WREC, but I try not to miss a chance to
ask the question...
Spencer
> -----Original Message-----
> From: Henrik Nordstrom [SMTP:hno@hem.passagen.se]
> Sent: Monday, August 02, 1999 5:07 PM
> To: Dawkins, Spencer [RICH1:2011-I:EXCH]
> Cc: 'Joe Touch'; wrec@cs.utk.edu
> Subject: Re: oh the irony
>
> Spencer Dawkins wrote:
>
> > I can't tell you this is the RIGHT response to discovering that your
> server
> > doesn't have the same notion of content-length as widely-deployed
> clients,
> > but this was discussed on one of the W3C mailing lists as one of the
> reasons
> > why persistent connections still aren't that common.
>
> Another probably more important reason is the move to more and more
> dynamically generated content where the content length isn't known until
> after the object has been transmitted (or in some cases buffered, where
> a content-length may be calculated on the fly from the buffer).
>
> Other reasons includes a mess of broken implementations in older
> browsers. Persistent connections wasn't documented until HTTP/1.1, and
> many of the early implemenations (and some of the later as well) didn't
> get it right. This mess, rather than bad server implementations may have
> forced many server maintainers to disable persistent connections.
>
> --
> Henrik Nordstrom
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST