The fallacy in the attached description is the implication that a persistent connection is established on any basis except hop-hop. I would suggest reading section 19.7.1 in rfc2068. There can be no such thing as "unwittingly forced into agreeing to a persistent connection" and I think the RFC2068 section explains the issues more accurately. Dave Morris On Fri, 17 Apr 1998 Dominic.Chambers@mimesweeper.com wrote: > > >>>>> "EW" == <ewindes@spyglass.com> writes: > > EW> OK, I too, am confused about why proxies MUST NOT establish > EW> persistent connections with 1.0 clients. If the client and > EW> origin server connections are handled separately, and if the > EW> proxy understands the 1.0 Keep-alive, what's the danger? > > Persistent connections in HTTP/1.0 must be established on a hop-by-hop > basis, so that intermediaries (proxies) are not forced into persistent > connections if they do not understand them. The connection: keep-alive > header allowed a client to request a persistent connection from an > origin server without consideration for intermediaries (end-to-end). > > To prevent this problem, clients connecting to origin servers via > intermediaries were required to send a proxy-connection: keep-alive > header instead which the proxy could convert to a plain connection: > keep-alive header if it also implemented persistent connections. > Origin servers only respond to the plain connection: keep-alive > headers, knowing that if they receive a proxy-connection: keep-alive > header that the proxy does not support persistent connections. This > works fine in this scenario: > > C <--> P <--> OS > > Proxy chains were, in theory, to be supported by ensuring that only > proxies at the end of the chain could perform keep-alive header > conversions so that upstream proxies were not unwittingly forced into > agreeing a persistent connection. Where P* is a proxy that will > perform keep-alive header conversions, then a typical scenario might > be: > > C <--> P <--> P <--> P* <--> OS > > Finally, the reason origin servers should not provide persistent > connections to clients is that if the last proxy in the chain supports > persistent connections, then the entire connection will be persistent > regardless of whether all the downstream proxies support persistent > connections. > > Proxy chains constructed in this way will never work because any proxy > that does not support persistent connections will wait for an end of > connection from the upstream proxy that will never arrive. If the > first proxy in our chain did not support persistent connections the > data flow would be: > > _ _ _ __ __ > |C| --> |P| --> |P| --> |P*| --> |OS| > | | | | <-- | | <-- | | <-- | | > > Hope that makes sense (it's not easy to explain without a drawing > board). > > > Cheers, > > > Dominic > ********************************************************************** > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify Content Technologies > on +44 118 9301300. > > This message has been generated by MIMEsweeper and certifies that the message and attachments have been swept for all known and recorded computer viruses. > MIMEsweeper 3.x protects your organization from content borne threats and malicious intent. Combined with firewalls MIMEsweeper provides a comprehensive network security solution. > > For information regarding the MIMEsweeper family of products: > > Phone: +44 118 9301300 > Fax: +44 118 9301301 > Email: info@mimesweeper.com > Support:msw.support@mimesweeper.com > World Wide Web: http://www.mimesweeper.com > > MIMEsweeper: Content Security for Networks > ********************************************************************** > >Received on Friday, 17 April 1998 11:04:42 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC