I forgot to say: I also changed the parser for "Authorization:" request header to "Proxy-Authorization:" and that parser works well. But the problem remains.
On Sun, Sep 20, 2009 at 11:24 AM, Fastream Technologies <ga...@fastream.com>wrote: > Hello, > > Even though the code works for reverse proxy, it does not when I make it a > part of IE/FF chain as forward proxy! In Answer401, I wrote: > > String AuthString = "auth"; > String staleString = String((FAuthDigestStale && lastCommand != > cproxyCommandPOST) ? ", stale=\"true\"" : ""); > String prefix = (Owner->Tag > 0 ? "https://"; : "http://";); > String URI = FPath; > headerHead += "Proxy-Authenticate: Digest " + // I only changed this line > from rproxy to forward proxy > GenerateDigestChallenge() + > ", domain=\"" + prefix + FAuthRealm + ":" + serverPort + "\"" + > ", uri=\"" + URI + "\"" + > //", algorithm=\"MD5\"" + > staleString + "\r\n"; > > and in ConnectionDataAvailable, before the processRequest ( I have my > descendent of THttpServer by the way): > > else if(!FRequestAuthorization.SubString(1, 6).AnsiCompareIC("Digest")) > { > FAuthDigestBody = ""; > FAuthenticated = AuthDigestGetParams(); > if(FAuthenticated) > { > username = FAuthUserName; // NO matter even the username is correct, > never reaches here! > String bufferPassword = serverPermissions->getUserPassword(username); > > I am not sure how to debug this as the data is encrypted. I know we were > the pioneers in digest coding that we had had coded in Bulgaria and then > Francois fixed it. But now it's a different story--forward proxy. Any idea > what's wrong? The forward proxy units were copied from reverse proxy ones > and then altered so the variable's reset points are exactly the same that > has been working in rproxy. I hope you can help. > > Thanks in advance, > > SZ > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
