Re: Confused about persistent connection for old clients
David W. Morris (dwm@xpasc.com)
Fri, 17 Apr 1998 10:56:08 -0700 (PDT)
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
> **********************************************************************
>
>