W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 1998

Re: Confused about persistent connection for old clients

From: David W. Morris <dwm@xpasc.com>
Date: Fri, 17 Apr 1998 10:56:08 -0700 (PDT)
To: Dominic.Chambers@mimesweeper.com
Cc: http-wg-request@cuckoo.hpl.hp.com, Andy Norman <ange@hplb.hpl.hp.com>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980417104356.23758H-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/61

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