| David Wang 2007-02-05, 7:19 am |
| I really do not know of a better newsgroup, and I do not believe this
is a client-side issue.
I do not believe you can dismiss my suggestion because your
observations simply do not disprove my point and actually support it
in many cases.
> 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.
The simplicity of the web service and "only requesting the name of the
authenticated user" have no relation to the size of the request. SSL
Client Certificates are negotiated before server even sees the data,
and Kerberos protocol of Integrated Authentication can affect the size
of that encrypted data such that SSL Client Certificates are received
outside of UploadReadAheadSize.
In other words, your actions were insufficient. You need to prove
either:
1. In your failing cases, Integrated Authentication used NTLM and not
Kerberos
2. SSL Certificates are read before UploadReadAheadSize
> 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.
No surprise since XPSP2 runs the same core as IIS5. This really proves
nothing.
> 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?
When you manually dismiss the dialog to select a certificate, IE does
NOT send a client certificate. This means that the processing of the
SSL Client Certificate is the issue -- which is exactly what I'm
saying.
In other words, I believe your observations support my point. Can you:
1. Confirm that Kerberos is used over Integrated Authentication and
SSL. If this machine is in a domain and you never configure
NTAuthenticationProviders to have NTLM to be default, then you are
using Kerberos
2. Check the size of the Kerberos ticket. Make the same request over
HTTP and with a network sniffer, determine the size of that Kerberos
Authorization: request header
The size of the Kerberos Authorization: header depends on the
authenticated Windows user and their domain membership. You really
cannot control the size of this blob, so there is no way you can
discount it as an issue without directly observing it.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Feb 5, 3:14 am, jacorona <jacor...@discussions.microsoft.com>
wrote:
> 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:
>
>
>
>
> - Show quoted text -
|