Re: Confused about persistent connection for old clients

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