El Martes, 20 de Octubre de 2009, Jacques Caron escribió: > Hi, > > What would be the point of doing this in pound rather than on the > back-end http server? Also it would conflict with cases where the > back-end does authentication itself, and of course there would be the > problem of communicating auth info to the back_end (when you do it on > Apache for instance you get the username in REMOTE_USER).
This would be for a specific scenario (XCAP protocol in top of HTTP) so the http servers already know they must not ask for auth. About the communication you are right, I forgot to mention that the proxy would add a header conatining the u...@domain after a succesulful authentication. > It might be more appropriate to do Proxy-authentication (i.e. 407 > instead of 401), Right, my fault. > but wouldn't that be more useful in a "forward" > proxy configuration rather than in a reverse proxy/load balancer > configuration? The point here is that I must implement digest auth (based on DB or Radius) in my XCAP servers (still in development of course), so for me it's the same if I do it in the proxy itself and it would be faster (C code VS Ruby code). Also Ruby lacks of a Radius library so perhaps it would be easier coding the radiuss-digest auth using the existing C library. Not sure if a "forward" proxy would be better here. The fact is that I do need load balancing and failover as my config files shows. The typical environment would be the following: - A server (quad-core) in Internet with public IP. - Pound listening in port 443 (HTTPS). - 4 instances of my Ruby XCAP/HTTP server running in same server (listening in localhost). - Pound does failover and load balancing between them. - Clients connect to the public IP in which Pound binds from anywhere in the world. I expect this must be a "reverse proxy configuration". Thanks a lot. -- Iñaki Baz Castillo <[email protected]> -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
