Subject: RE: Chained proxies, persistent connections, authentication

From: Rob Maidment <[email-masked]>
Date: Thu, 23 Oct 2003 16:44:31 +0100

Just to throw some more fuel on the fire, this is an excerpt from WRL
Research Report 95/4 "The Case for Persistent-Connection HTTP" (Jeffrey
Mogul, May 95):

"A persistent-connection model for Web access potentially provides the
opportunity for other
improvements to HTTP [20]. For example, if authentication could be done
per-connection rather
than per-request, that should significantly reduce the cost of robust
authentication, and so might
speed its acceptance."

Rob

>  -----Original Message-----
> From: 	Rob Maidment  
> Sent:	23 October 2003 15:32
> To:	[email-masked]'
> Subject:	Chained proxies, persistent connections, authentication
> 
> 
> I am currently investigating a problem that occurs in this type of
> scenario:
> 
> browser -> proxy1 -> proxy2 -> server
> 
> Proxy1 is actually a Squid proxy, it is passing though the end-user
> authentication to proxy2.  The problem occurs because proxy1 is reusing
> connections to proxy2 for requests from different users, but proxy2 is
> only authenticating the first request on each new connection.  This means
> that subsequent requests are not being authenticated, and these requests
> are being treated as if they originated from the first user to use the
> connection.  
> 
> Which proxy is at fault?  I understood that one of the intended benefits
> of persistent connections was that a proxy would only have to authenticate
> the first request on each connection, which is a huge performance benefit.
> But ths assumes that a downstream proxy that passes through user
> authentication will not re-use the connection for different users.  Having
> said that, so far I have been unable to find any specification that says a
> proxy need only authenticate the first request on each connection.
> 
> I'd appreciate any thoughts on the matter,
> 
> 
> Rob Maidment.
> 

---------------------------------------------------------------------------------------------------------------
Clearswift monitors, controls and protects all its messaging traffic in 
compliance with its corporate email policy using Clearswift products. 
Find out more about Clearswift, its solutions and services at 
www.clearswift.com.
***********************************************************************************
This communication is confidential and may contain privileged 
information intended solely for the named addressee(s). It may not 
be used or disclosed except for the purpose for which it has been 
sent. If you are not the intended recipient, you must not copy, 
distribute or take any action in reliance on it. Unless expressly stated, 
opinions in this message are those of the individual sender and not of 
Clearswift. If you have received this communication in error, please 
notify Clearswift by emailing [email-masked] quoting the 
sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain.
This footnote confirms that this email message has been swept by 
MIMEsweeper for Content Security threats, including computer viruses.

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 23 Oct 2003 10:37:48 -0700

"A persistent-connection model for Web access potentially provides
    the opportunity for other improvements to HTTP [20]. For example,
    if authentication could be done per-connection rather than
    per-request, that should significantly reduce the cost of robust
    authentication, and so might speed its acceptance."

As the author of that paragraph, I should point out that it is
speculative ... "IF authentication COULD BE done per-connection"
... and although there might have been a plausible alternate
universe, in 1995 when I wrote that, in which HTTP authentication
could have been designed to be per-connection, this didn't
happen.  (Maybe SSL is that alternate universe; HTTP/1.1 is not.)

RFC2616 and RFC2617 are both dated June 1999.  That Research
Report is dated 4 years earlier.  Please be careful not to confuse
people about which document matters more.

-Jeff