| jacorona 2007-02-05, 7:19 am |
| Many thanks again David.
However, I don't think the problem has to do with the size of the request
being too large.
In fact, this is only a test I wrote to check whether there could be any
problem with this aproach and the web service and the method are minimal. I
am only requesting the name of the authenticated user the web service sees.
Incidentally, I have also checked this behaviour on XP SP2 (.Net 2.0 and IIS
5.0) and it works the same; i.e. the client also times out.
I am suspecting that the problem resides on the client part. In fact, if I
access the web service from a browser (requesting the WSDL, for instance) via
https:, after manually dismissing the dialog to select a certificate, it
works fine using integrated security. What o how works IE in this case, so
that one can do the same programmatically?
If you think this could not be the right discussion group, could you please
point me to a more appropiate one?
Many thanks again for your time.
"David Wang" wrote:
> Hmm... you may be seeing a known problem with IIS5 and
> ClientCertificate on large requests. And Kerberos tickets can make
> request large.
>
> This is technically a flaw within the SSL specification, and you can
> work around it by increasing the size of UploadReadAheadSize to
> something larger than the 49152 default (i.e. 102400). You don't want
> it too large since that would constitute a DOS security vulnerability.
>
> I know this issue is handled in IIS6, but I do not think it was fixed
> in IIS5 - Windows 2000 was already at end of life and no customer
> request = no porting. Changing UploadReadAheadSize *may* help on IIS5.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
|