iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
We are using WebGrid 6.0.7200.220 on an ASP.NET 4.0 site with Integrated Windows authentication. The website is slow due to a slow network. We saw that every server request is made of three requests (first is an anonymous attempt with 401 result, second is another attempt without any data and with the Authorization header and again 401 result, third request is successful 200). These three requests are made for every image, every javascript, etc. that is not in the cache of the browser.
To avoid these multiple requests we redesigned the application. Now we'er using anonymous authentication. In global.asax/Session_Start we redirect to a Login.aspx page. Login.aspx is the only page set to Integrated Windows authentication. There we retrieve the user information and store this in the Session object. Then we redirect to the normal application. In the application we just read the user information from the Session object instead. This works great - except that this broke WebGrid somehow.
I de-obfuscated the WebGrid js code and started debugging. I found out that our code calls (from the client-side row select event handler) a js function that calls SendCustomRequest (with a delay of a half second due to another bug in WebGrid). I could debug this call into Intersoft's js file that it does this:
this.Send=function(... var vf1026=this.XmlHttp ... vf1026.open("POST",... vf1026.setRequestHeader("Content-Type",... vf1026.onreadystatechanged=... vf1026.send(xxx); (xxx is "WebGridRequest=...(encoded xml with request action=custom))
So everything looks good. But what I see from the network trace protocol is that actually the POST request is being made, but with these request headers:
... Cookie: ASP.NET_SessionId=... Authorization: Negotiate ... Content-Length: 0
The server does not expect this and answers with a 100 Continue and then 200 OK with the full page again. The client didn't expect this answer and calls the client side error handler, which redirect to an error page.
So what went wrong here? I can see that the WebGrid sends an empty Content-Length with the POST request and it tries to authenticate (see Authorization header). That's the problem. No other request to the server ever does authenticate again. Remember that we are using anonymous authentication. For some reason WebGrid (or the component it is using) thinks it needs to authenticate and sends this Authorization header. Why is this happening and how can we avoid this problem?
When I set IIS back to Integrated Windows authentication, everything is working again, but this is what we wanted to avoid.
We are considering to upgrade to the newest version, but if these bugs continue, we will rather replace WebGrid. I don't want to "try" with another version. Please tell me if this is a known bug and already fixed, or if not, please investigate. Thanks.
Hi Yudi. Investigating this issue further, I found that the same problem happens with the asp:UpdatePanel on AJAX POST requests. With this information I could google a solution and found this:
http://stackoverflow.com/questions/1238480/why-content-length-is-0-while-sending-post-request-with-xmlhttprequest-object
So there seems to be a bug or design flaw to exist in Internet Explorer handling requests. When once authenticated and Keep-Alive is active, sending another request with XMLHttpRequest object (that's what you are using I assume), causes the object to try to authenticate with Content-Length=0 and fails.
Workaround is to separate the pages with Integrated Windows authentication into a separate virtual directory. I had the Login.aspx in the root folder. Moving this page to a folder "auth" and setting the Directory Security to Integrated Windows on this folder (instead of only on the file) solved the problem.
I will need your hand to investigate this problem. Please try to use HttpWatch and then investigate the response of each script resource. Please compare the result between the two conditions, when uses Integrated Windows authentication and anonymous authentication.
If you manage to get the exact error message, please post it.
Hi Yudi. I think I outlined the differences clearly in my initial post. I'm not sure what else you would need. I'll try to explain again.
With Integrated Windows authentication, I have these three requests when clicking on the WebGrid:
--> POST URL page.aspx Cookie: ASP.NET_SessionId=.. Content-Length: 10181 Content: WebGridRequest=... <-- 401 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM --> POST URL page.aspx Cookie: ASP.NET_SessionId=.. Content-Length: 0 Authorization: Negotiate ... <-- 401 WWW-Authenticate: Negotiate ... --> POST URL page.aspx Cookie: ASP.NET_SessionId=.. Authorization: Negotiate ... Content-Length: 10181 Content: WebGridRequest=... <-- 200 Content: <isnet.webui.webgrid><action...
And with the new code with anonymous authentication, for the same action we get:
--> POST URL page.aspx Cookie: ASP.NET_SessionId=... Content-Length: 0 Authorization: Negotiate ... <-- 100 <-- 200 Content-Length: 95777 Content: (entire page)
The problem is that for some reason the request has no content, but an Authorization header. I don't know where this comes from. Maybe something from the browser (IE8) or client component doing the request. Maybe the browser/component "remembers" somehow that for this site an authorization was made earlier (on the Login.aspx page) (Connection is always Keep-Alive) and therefore tries to re-authenticate right away. You can see that the request matches the second request in the Windows authentiction requests. As the server doesn't support Integrated Windows authentication on this page, it fails. So I'm not sure how to tell the client not to do such requests. Maybe there's an option in the component to set this that you forgot to set?
Normal requests for images look like this:
--> GET URL myfile.gif Cookie: ASP.NET_SessionId=... <-- 200 Content-Length: 205 Content: GIF89a...
As you can see, there's no Authorization header. Maybe as a workaround I can enable Integrated Windows authentication as a second option beside Anonymous. That should work, because the browser always tries anonymous first (by definition). In this case this avoids our optimization, but also avoids the crash. But it would still be good to find the problem.
Glad to hear the good news and thank you very much for sharing the solution with us. I’m sure that your post will be useful for members who have similar problems.
Thanks again for your message.
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname
Creating your account...