CreateRequest very slow

iZ

unread,

Mar 11, 2010, 11:55:05 AM3/11/10

to DotNetOpenAuth

I'm using DNOA with to authenticate against a Google Domain using
OpenID. I noticed it is very slow. After adding some debug statements,
I've narrowed it down to this line:

req = openid.CreateRequest(OpenIDOP, realm);

Any idea why this would be so slow? > 5 seconds.

Øyvind Sean Kinsey

unread,

Mar 11, 2010, 12:07:51 PM3/11/10

to dotnet...@googlegroups.com

You should enable logging similar to the one used in the samples, for instance the OpenIdRelyingPartyWebForms.

Add the log4net dll, the config sections and adjust the log4net appenders to your likeing, the RollingFileAppender is probably the easiest to use.

That way you can see each action performed by DNOA in order to run CreateRequest(..

Øyvind Sean Kinsey
oyv...@kinsey.no
http://kinsey.no/blog/index.php/about/

Andrew Arnott

unread,

Mar 11, 2010, 12:11:21 PM3/11/10

to dotnetopenid

The only slowdown I can imagine of that magnitude would be the outgoing HTTP request itself. Perhaps the firewall settings are incorrect, or DNS resolution is slow. Try hitting the same URL you're passing to CreateRequest using Intenret Explorer and see how long it takes to come up.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

2010/3/11 Øyvind Sean Kinsey <oyv...@kinsey.no>

Israel Derdik

unread,

Mar 11, 2010, 12:18:48 PM3/11/10

to dotnet...@googlegroups.com

Andrew, the slow down is happening well before I call req.RedirectToProvider(); Does CreateRequest make an HTTP call too?

iZ

unread,

Mar 11, 2010, 12:54:52 PM3/11/10

to DotNetOpenAuth

Ok - I've enabled logging and the results look interesting (big paste
below). Any idea what those WebExceptions are?

:

2010-03-11 12:50:00,117 [3] INFO DotNetOpenAuth - DotNetOpenAuth,
Version=3.4.0.10015, Culture=neutral, PublicKeyToken=2780ccd10d57b246
(official)
2010-03-11 12:50:00,137 [3] INFO DotNetOpenAuth - Reporting will use
isolated storage with scope: User, Domain, Assembly
2010-03-11 12:50:00,329 [3] INFO DotNetOpenAuth.Messaging.Channel -
Scanning incoming request for messages:
http://chicken/marketplace/webv2/loginopenid.aspx?gdomain=prem-test.worth1000.com&redirectto=%2fgooglebrowser%3fgdomain%3dprem-test.worth1000.com%26gdomainhash%3dc28c476114aab901bb125172819e21d0
2010-03-11 12:50:00,611 [3] INFO DotNetOpenAuth.Yadis - Found host-
meta for prem-test.worth1000.com at:
https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test.worth1000.com
2010-03-11 12:50:00,612 [3] INFO DotNetOpenAuth.Yadis - Found link to
XRDS at https://www.google.com/accounts/o8/site-xrds?ns=2&hd=prem-test.worth1000.com
in host-meta document https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test.worth1000.com.
2010-03-11 12:50:05,616 [3] ERROR DotNetOpenAuth.Http - WebException
from https://www.google.com/accounts/o8/user-xrds?uri=http:%2F%2Fprem-test.worth1000.com%2F:
<!DOCTYPE html>
<html>
<head>
<title>Google Accounts</title>
<style type="text/css">
body {font-family: arial,sans-serif;}
.body {margin: 15px 15px; }
</style>
</head>
<body dir="" ><style type="text/css">
.aligns {
text-align: ;
}
.margins {
margin-: 13px;
}
.floats-normal {
float: ;
}
.floats-reverse {
float: ;
margin-top: 17px;
}
</style>
<div class="header margins" style="height: 59px; margin: 33px 15px
9px 15px;">
<img src="https://www.google.com/intl//images/logos/
accounts_logo.gif" alt="Google Accounts" height="40px;"/>
</div>
<div style="clear:both;"></div>
<div class="body">
</div>
<div class="footer" style="color: #666; font-size: smaller; margin:
50px 15px 0 15px; text-align: center;">
©2009 Google -
<a href="http://www.google.com">Google Home</a> -
<a href="https://www.google.com/accounts/TOS?hl=">Terms of Service</
a> -
<a href="http://www.google.com/intl//privacy.html">Privacy Policy</
a> -
<a href="http://www.google.com/support/accounts?hl=">Help</a>
</div>
</body>
</html>
2010-03-11 12:50:05,617 [3] WARN DotNetOpenAuth.Yadis - HTTP GET
error while retrieving described-by XRDS document
https://www.google.com/accounts/o8/user-xrds?uri=http%3A%2F%2Fprem-test.worth1000.com%2F:
DotNetOpenAuth.Messaging.ProtocolException: Error occurred while
sending a direct message or getting the response. --->
System.Net.WebException: The remote server returned an error: (400)
Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) in c:\TeamCity\buildAgent
\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging
\StandardWebRequestHandler.cs:line 126
--- End of inner exception stack trace ---
at
DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) in c:\TeamCity\buildAgent
\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging
\StandardWebRequestHandler.cs:line 172
at
DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse(HttpWebRequest
request, DirectWebRequestOptions options) in c:\TeamCity\buildAgent
\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging
\UntrustedWebRequestHandler.cs:line 250
at
DotNetOpenAuth.OpenId.HostMetaDiscoveryService.GetXrdsResponse(UriIdentifier
identifier, IDirectWebRequestHandler requestHandler, Uri xrdsLocation)
in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth
\OpenId\HostMetaDiscoveryService.cs:line 306
at
DotNetOpenAuth.OpenId.HostMetaDiscoveryService.GetExternalServices(IEnumerable`1
xrds, UriIdentifier identifier, IDirectWebRequestHandler
requestHandler) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src
\DotNetOpenAuth\OpenId\HostMetaDiscoveryService.cs:line 191
2010-03-11 12:50:05,745 [3] INFO DotNetOpenAuth.OpenId - Further
discovery on 'http://prem-test.worth1000.com/' was stopped by the
HostMetaDiscoveryService discovery service.
2010-03-11 12:50:05,758 [3] INFO DotNetOpenAuth.Yadis - Performing
discovery on user-supplied identifier: http://prem-test.worth1000.com/
2010-03-11 12:50:05,832 [3] INFO DotNetOpenAuth.Messaging.Channel -
Prepared outgoing AssociateUnencryptedRequest (2.0) message for
https://www.google.com/a/prem-test.worth1000.com/o8/ud?be=o8:
openid.assoc_type: HMAC-SHA256
openid.session_type: no-encryption
openid.mode: associate
openid.ns: http://specs.openid.net/auth/2.0

2010-03-11 12:50:06,317 [3] INFO DotNetOpenAuth.Messaging.Channel -
Processing incoming AssociateUnencryptedResponse (2.0) message:
mac_key: Eq6fvsEcAqQyzp3xBa8hXvHzikjcuEbp+g0K50kG+k8=
assoc_handle:
AOQobUfy3qs9tRcrPLiW-8eXmr6CqkmDndW_e76-9lV5lKRIDiEFVU0PWhtXjf3c97WeswpZ
assoc_type: HMAC-SHA256
session_type: no-encryption
expires_in: 46800
ns: http://specs.openid.net/auth/2.0

2010-03-11 12:50:06,394 [3] INFO DotNetOpenAuth.Messaging.Channel -
Prepared outgoing CheckIdRequest (2.0) message for
https://www.google.com/a/prem-test.worth1000.com/o8/ud?be=o8:
openid.claimed_id: http://specs.openid.net/auth/2.0/identifier_select
openid.identity: http://specs.openid.net/auth/2.0/identifier_select
openid.assoc_handle:
AOQobUfy3qs9tRcrPLiW-8eXmr6CqkmDndW_e76-9lV5lKRIDiEFVU0PWhtXjf3c97WeswpZ
openid.return_to:
http://chicken/marketplace/webv2/loginopenid.aspx?gdomain=prem-test.worth1000.com&redirectto=%2Fgooglebrowser%3Fgdomain%3Dprem-test.worth1000.com%26gdomainhash%3Dc28c476114aab901bb125172819e21d0&dnoa.userSuppliedIdentifier=prem-test.worth1000.com
openid.realm: http://chicken/
openid.mode: checkid_setup
openid.ns: http://specs.openid.net/auth/2.0
openid.ns.alias3: http://openid.net/srv/ax/1.0
openid.alias3.required: alias1
openid.alias3.mode: fetch_request
openid.alias3.type.alias1: http://axschema.org/contact/email
openid.alias3.count.alias1: 1

2010-03-11 12:50:06,839 [3] INFO DotNetOpenAuth.Yadis - Found host-
meta for prem-test.worth1000.com at:
https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test.worth1000.com
2010-03-11 12:50:06,839 [3] INFO DotNetOpenAuth.Yadis - Found link to
XRDS at https://www.google.com/accounts/o8/site-xrds?ns=2&hd=prem-test.worth1000.com
in host-meta document https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test.worth1000.com.
2010-03-11 12:50:16,491 [3] INFO DotNetOpenAuth.OpenId - Further
discovery on 'http://prem-test.worth1000.com/openid?
id=106682635961859422467' was stopped by the HostMetaDiscoveryService
discovery service.
2010-03-11 12:50:16,492 [3] INFO DotNetOpenAuth.OpenId - Received
identity assertion for http://prem-test.worth1000.com/openid?id=106682635961859422467
via https://www.google.com/a/prem-test.worth1000.com/o8/ud?be=o8.

On Mar 11, 12:07 pm, Øyvind Sean Kinsey <oyv...@kinsey.no> wrote:
> You should enable logging similar to the one used in the samples, for
> instance the OpenIdRelyingPartyWebForms.
> Add the log4net dll, the config sections and adjust the log4net appenders to
> your likeing, the RollingFileAppender is probably the easiest to use.
>
> That way you can see each action performed by DNOA in order to run
> CreateRequest(..
>
> Øyvind Sean Kinsey

> oyv...@kinsey.nohttp://kinsey.no/blog/index.php/about/

Andrew Arnott

unread,

Mar 11, 2010, 7:37:00 PM3/11/10

to dotnetopenid

Andrew, the slow down is happening well before I call req.RedirectToProvider(); Does CreateRequest make an HTTP call too?

Yes, absolutely. CreateRequest must perform "discovery" on the identifier you pass to it, which requires at least one, perhaps several, outbound HTTP requests. These may take time, or in the case suggested by the logs you included, may even fail at times due to slow servers hosting the OpenID identifier, or just server failure. It looks like the remote server is returning HTTP 400 responses, indicating a configuration problem on the remote end.

Since this looks like a Google Apps for Domains scenario, I'd contact the domain admin or Google support to find out what configuration could possibly be wrong that would result in an HTTP 400 coming back from them.

That said, it looks like a subsequent request attempt in your log succeeded. I don't know what would explain Google failing a response on one instance and succeeding on the next.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

2010/3/11 iZ <ide...@gmail.com>

iZ

unread,

Mar 12, 2010, 10:04:58 AM3/12/10

to DotNetOpenAuth

It looks like all requests to https://www.google.com/accounts/o8/user-xrds?....
failed. Which is the call for user discovery that succeeded? Is it
possible to force the code to query there first?

On Mar 11, 7:37 pm, Andrew Arnott <andrewarn...@gmail.com> wrote:
> > Andrew, the slow down is happening well before I call
> > req.RedirectToProvider(); Does CreateRequest make an HTTP call too?
>
> Yes, absolutely. CreateRequest must perform "discovery" on the identifier
> you pass to it, which requires at least one, perhaps several, outbound HTTP
> requests. These may take time, or in the case suggested by the logs you
> included, may even fail at times due to slow servers hosting the OpenID
> identifier, or just server failure. It looks like the remote server is
> returning HTTP 400 responses, indicating a configuration problem on the
> remote end.
>
> Since this looks like a Google Apps for Domains scenario, I'd contact the
> domain admin or Google support to find out what configuration could possibly
> be wrong that would result in an HTTP 400 coming back from them.
>
> That said, it looks like a subsequent request attempt in your log succeeded.
> I don't know what would explain Google failing a response on one instance
> and succeeding on the next.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>

> 2010/3/11 iZ <ider...@gmail.com>

>
>
>
> > Ok - I've enabled logging and the results look interesting (big paste
> > below). Any idea what those WebExceptions are?
>
> > :
>
> > 2010-03-11 12:50:00,117 [3] INFO DotNetOpenAuth - DotNetOpenAuth,
> > Version=3.4.0.10015, Culture=neutral, PublicKeyToken=2780ccd10d57b246
> > (official)
> > 2010-03-11 12:50:00,137 [3] INFO DotNetOpenAuth - Reporting will use
> > isolated storage with scope: User, Domain, Assembly
> > 2010-03-11 12:50:00,329 [3] INFO DotNetOpenAuth.Messaging.Channel -
> > Scanning incoming request for messages:
>

> >http://chicken/marketplace/webv2/loginopenid.aspx?gdomain=prem-test.w...

> > 2010-03-11 12:50:00,611 [3] INFO DotNetOpenAuth.Yadis - Found host-
> > meta for prem-test.worth1000.com at:
>

> >https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test...

> > 2010-03-11 12:50:00,612 [3] INFO DotNetOpenAuth.Yadis - Found link to
> > XRDS at

> >https://www.google.com/accounts/o8/site-xrds?ns=2&hd=prem-test.worth1...
> > in host-meta document
> >https://www.google.com/accounts/o8/.well-known/host-meta?hd=prem-test....

> > 2010-03-11 12:50:05,616 [3] ERROR DotNetOpenAuth.Http - WebException
> > from

> >https://www.google.com/accounts/o8/user-xrds?uri=http:%2F%2Fprem-test...

> >https://www.google.com/accounts/o8/user-xrds?uri=http%3A%2F%2Fprem-te...

> > DotNetOpenAuth.OpenId.HostMetaDiscoveryService.GetExternalServices(IEnumera ble`1

> >http://chicken/marketplace/webv2/loginopenid.aspx?gdomain=prem-test.w...

> > openid.realm:http://chicken/
> > openid.mode: checkid_setup
> > openid.ns:http://specs.openid.net/auth/2.0
> > openid.ns.alias3:http://openid.net/srv/ax/1.0
> > openid.alias3.required: alias1
> > openid.alias3.mode: fetch_request
> > openid.alias3.type.alias1:http://axschema.org/contact/email
> > openid.alias3.count.alias1: 1
>
> > 2010-03-11 12:50:06,649 [3] INFO DotNetOpenAuth.Messaging.Channel -
> > Scanning incoming request for messages:
>

> >http://chicken/marketplace/webv2/loginopenid.aspx?gdomain=prem-test.w...

> > 2010-03-11 12:50:06,658 [3] INFO DotNetOpenAuth.Messaging.Channel -
> > Processing incoming PositiveAssertionResponse (2.0) message:
> > openid.claimed_id:
> >http://prem-test.worth1000.com/openid?id=106682635961859422467
> > openid.identity:
> >http://prem-test.worth1000.com/openid?id=106682635961859422467
> > openid.sig: 4JtdHn8yjyDflxUdj27wL4g8Cw2rcfdEnshIfrTbizI=
> > openid.signed:
>
> > op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle,ns.ex t1,ext1.mode,ext1.type.alias1,ext1.value.alias1
> > openid.assoc_handle:

> > AOQobUfy3qs9tRcrPLiW-8eXmr6CqkmDndW_e76-9lV5lKRIDiEFVU0PWhtXjf3c97WeswpZ...
>
> read more »

Andrew Arnott

unread,

Mar 12, 2010, 12:31:42 PM3/12/10

to dotnetopenid

On Fri, Mar 12, 2010 at 7:04 AM, iZ <ide...@gmail.com> wrote:

It looks like all requests to https://www.google.com/accounts/o8/user-xrds?....
failed. Which is the call for user discovery that succeeded? Is it
possible to force the code to query there first?

The succeeding call to user-xrds?... is not shown in the log because for that particular request only failures are logged. The failure doesn't cause overall login failure because that was a step of looking for user service endpoints during the phase when really we're only interested in the OP service endpoint, which we can find right in that XRDS.

I think there is room for optimization here, in that we may not need to check for the user-xrds file until after we've received an assertion. That would avoid the exception you're seeing here.

That said, the fact that Google took 5 seconds to respond with an error seems unacceptably slow on their part. When I tested it on my machine the first time logging it also took around 5 seconds. After that it went much more quickly -- oddly.

I'll research this further to see if we can safely avoid the first user-xrds request. But please file a bug on http://trac.dotnetopenauth.net/ to make sure I don't forget it. Thanks for the report.

iZ

unread,

Mar 16, 2010, 10:08:07 AM3/16/10

to DotNetOpenAuth

Andrew, I sent this question to Google to see if there is anything
wrong on their end and this was the response I got:

----
As for why the user XRDS lookup is failing, the thing that looks odd
with what you sent is the uri parameter should be the full claimed ID
of the user (and properly URI encoded.) It should look more like:

http://www.google.com/accounts/o8/user-xrds?uri=http%3A%2F%2Fprem-test.worth1000.com%2Fopenid%3Fid%3D1234567890

Not sure if it is really making that particular request or if it just
got truncated in the logs. But its worth looking into more to see if
there is a bug in your code or in the underlying library regarding how
it is doing the user xrds lookup.
----

Does this make sense and is it correctable in the library?

On Mar 12, 1:31 pm, Andrew Arnott <andrewarn...@gmail.com> wrote:

> request. But please file a bug onhttp://trac.dotnetopenauth.net/<http://trac.dotnetopenauth.net:8000/>

Andrew Arnott

unread,

Mar 16, 2010, 11:43:38 AM3/16/10

to dotnetopenid

Yes, it does make sense and seems to agree with my own analysis. They didn't seem to address the extremely slow request though -- only that the request shouldn't be made.

Can you open a bug for this on http://trac.dotnetopenauth.net/

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

2010/3/16 iZ <ide...@gmail.com>

Israel Derdik

unread,

Mar 16, 2010, 12:42:08 PM3/16/10

to dotnet...@googlegroups.com

Thanks - added it as #185

iZ

unread,

Mar 17, 2010, 5:49:44 PM3/17/10

to DotNetOpenAuth

Google has confirmed that the speed is an issue but that they probably
won't get around to fixing it any time soon because it only happens on
the bad request. Anything you can do on that bug would be greatly
appreciated.

On Mar 16, 11:43 am, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Yes, it does make sense and seems to agree with my own analysis. They
> didn't seem to address the extremely slow request though -- only that the
> request shouldn't be made.
>

> Can you open a bug for this onhttp://trac.dotnetopenauth.net/

> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>

> 2010/3/16 iZ <ider...@gmail.com>

>
>
>
> > Andrew, I sent this question to Google to see if there is anything
> > wrong on their end and this was the response I got:
>
> > ----
> > As for why the user XRDS lookup is failing, the thing that looks odd
> > with what you sent is the uri parameter should be the full claimed ID
> > of the user (and properly URI encoded.) It should look more like:
>

> >http://www.google.com/accounts/o8/user-xrds?uri=http%3A%2F%2Fprem-tes...

Ondrej Hrebicek

unread,

Apr 2, 2010, 8:26:47 PM4/2/10

to DotNetOpenAuth

Andrew, have you had a chance to get any more insight into whether the
first user-xrds request can be safely skipped? The delay is pretty
substantial -- and I don't see it going away on retries -- and makes
for a pretty poor user experience. I couldn't find anything to
indicate we'd have to go after additional XRDS docs when discovering
the OP myself. Thanks for looking into this, we appreciate everything
you're doing with DNOA.

On Mar 12, 10:31 am, Andrew Arnott <andrewarn...@gmail.com> wrote:

> On Fri, Mar 12, 2010 at 7:04 AM, iZ <ider...@gmail.com> wrote:
> > It looks like all requests to
> >https://www.google.com/accounts/o8/user-xrds?....
> > failed. Which is the call for user discovery that succeeded? Is it
> > possible to force the code to query there first?
>
> The succeeding call to user-xrds?... is not shown in the log because for
> that particular request only failures are logged. The failure doesn't cause
> overall login failure because that was a step of looking for user service
> endpoints during the phase when really we're only interested in the OP
> service endpoint, which we can find right in that XRDS.
>
> I think there is room for optimization here, in that we may not need to
> check for the user-xrds file until after we've received an assertion. That
> would avoid the exception you're seeing here.
>
> That said, the fact that Google took 5 seconds to respond with an error
> seems unacceptably slow on their part. When I tested it on my machine the
> first time logging it also took around 5 seconds. After that it went much
> more quickly -- oddly.
>
> I'll research this further to see if we can safely avoid the first user-xrds

> request. But please file a bug onhttp://trac.dotnetopenauth.net/<http://trac.dotnetopenauth.net:8000/>

Andrew Arnott

unread,

Apr 2, 2010, 9:34:34 PM4/2/10

to dotnetopenid

Hi Ondrej,

I have a special build of DNOA that avoids the first download of the user-xrds. But it turned out to not solve the problem. Google just hung for 4.5 seconds on a subsequent HTTP request that was a core part of the spec that couldn't be avoided.

....

Ah, crap. I think I know what the problem is. Anyone interested in testing the new build to see if it resolves the issue let me know.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

Ondrej Hrebicek

unread,

Apr 3, 2010, 2:59:04 PM4/3/10

to DotNetOpenAuth

Andrew,

The hang wasn't caused by X509Certificate.Verify() and
X509Chain.Build(), was it? I later realized that's what the real
problem was, at least on my machine. Where can I get the new build?

> > dotnetopenid...@googlegroups.com<dotnetopenid%2Bunsubscribe@google groups.com>

Andrew Arnott

unread,

Apr 3, 2010, 3:55:51 PM4/3/10

to dotnetopenid

I haven't seen a delay due to the X509Chain code (yet). But I'll double check that. My fix was for some dangling HTTP connections the library left open during Google Apps discovery that causes .NET to just hang while the connections timeout.

You can download the fixed build here:
http://cid-063d0c265f96e43d.skydrive.live.com/self.aspx/.Public/DotNetOpenAuth.zip
Please let me know how it goes for you so I know whether it fixes the problem.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Ondrej Hrebicek

unread,

Apr 3, 2010, 5:52:58 PM4/3/10

to DotNetOpenAuth

Andrew,

It turns out the sole reason for the slowness I was seeing was the
cert verification process. Verify() and Build() while running inside
IIS were consistently taking about 5 seconds to complete each --
Verify() was actually returning false, which caused Build() to run
from within VerifyCertChain(), which eventually succeeded. I ran the
same code in a simple test app I wrote and the delays didn't repro. I
then ran the same test app as NT AUTHORITY\System and the delays
returned -- but only the first time. Subsequent runs under the System
account were fine. From then on, IIS was fine too.

When I realized your custom build wasn't obviously addressing my cert
problem I returned to my own from GitHub's source. That one's running
fast now too, so I suppose Google also addressed the delay on Bad
Requests.

On Apr 3, 12:55 pm, Andrew Arnott <andrewarn...@gmail.com> wrote:
> I haven't seen a delay due to the X509Chain code (yet). But I'll double
> check that. My fix was for some dangling HTTP connections the library left
> open during Google Apps discovery that causes .NET to just hang while the
> connections timeout.
>

> You can download the fixed build here:http://cid-063d0c265f96e43d.skydrive.live.com/self.aspx/.Public/DotNe...

Israel Derdik

unread,

Apr 3, 2010, 11:21:46 PM4/3/10

to dotnet...@googlegroups.com

Andrew, will this build fix my woes as well?

Sent from my mobile device.

Andrew Arnott

unread,

Apr 4, 2010, 12:20:06 AM4/4/10

to dotnetopenid

I hope so. Please try it.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

Andrew Arnott

unread,

Apr 9, 2010, 1:24:38 AM4/9/10

to dotnetopenid

Hey folks, did either of you try the new build? Did it solve your problem?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

Reply all

Reply to author

Forward