lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: > Is it really a problem if the client is sent a new auth challenge? If the > client connection is closed because the server went away, the client will > most likely need to refresh the page, which will result in a new auth > challenge being issued anyway.
Yes, but here the client expects the auth challenge. The problem with sending a new auth challenge on an already authenticated NTLM/Negotiate is that as far as the client knows this connection to the web server is already authenticated, and receiving a new auth challenge on the same connection can only mean that the previously sent credentials isn't acceptable for the requested object and the end-user has to be queried for a new login.. or at least so is the principle behind how authentication works in HTTP. Now with Microsoft already ignoring the specifications in many other aspects they probably ignore this as well.. Closing a persistent connection at any time after the previous reply has been sent is something clients working with persistent connections MUST handle, and the client SHOULD automatically retry the request in such situation (with just a few exceptions like POST/PUT where the end-user SHOULD be queried if the operation should be retried) > We've been using a patch that allows NTLM auth to work through our proxies > for a while now. The version we're using does depend on the tproxy patch > that we've also applied, and it essentially adds the client's ip address and > port to the pconn key when the server connection is spoofing the client's ip > address. As a result of using the existing pconn code, we do not handle the > closing of the server connection any differently from any other persistent > connection failing. This has not generated errors that I have heard of from > any client using our proxy servers, and we do transparently proxy all our > client access to web servers. Good. This would simplify things quite a bit. > Having seen your patch, I've added the Proxy-Support: headers, and also > added a "pinning" flag to the request->flags struct to allow identification > of a pinned connection. I've attached a modified version of the patch we're > using for comment, as it uses the existing persistent connection methods and > does not add any new sections of code that will terminate connections (and > this version will apply to the squid 2.5 tree without needing the tproxy > patch applied). Great! > I've not looked into the http specs to see if I'm breaking any rules here, > but in practice we're not seeing problems with this style of connection > pinning. The whole idea is outside of specs anyway. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
