Hi!

I'm trying to upload a large file, actually a huge one to a web server. Obviously I have to set AllowWriteStreamBuffering = false in order to avoid heavy memory usage on the client side. It works fine with Anonymous access but fails on Integrated Auth with "This request requires buffering data to succeed." error. I've tried to pre-authenticate the connection with HEAD request like MS KB describes for IIS server: http://support.microsoft.com/kb/908573/en-us, but no luck neither (500th error). Is there any workaround for my strange problem?


PS I must admit it's a cool product!

Sorry for late reply.

Here goes the sample code (I hope VS2010 is Ok?).
http://dl.dropbox.com/u/7549375/UploadTest.zip

Server and client are on the same computer in a trivial case (no domain), I'll try it within a domain.
There's no matter how big the file I'm trying to upload, I have the same error even on small ones. the only difference is I can not switch off AllowWriteStreamBuffering on files about 2-3 GBytes in size because it will consume a lot of memory for processing.

Thanks!

First of all, I've found solution (see the last part of the message).

Actually, in this test example everything ends up with a single 401 unauthorized response.

But I receive 500 error in case I try to preauthenticate request with HEAD, like this:

// Pre-authenticate the request.
wr = (HttpWebRequest)HttpWebRequest.Create(url);
wr.Credentials = System.Net.CredentialCache.DefaultCredentials;
wr.UnsafeAuthenticatedConnectionSharing = true;
wr.Method = "HEAD";
wr.Timeout = 10000;
wresp = (HttpWebResponse)wr.GetResponse();
wresp.Close();

---

HEAD http://home7/Server/WebService.asmx/UploadFile HTTP/1.1
Host: home7
Connection: Keep-Alive

---

HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Date: Tue, 15 May 2012 21:34:26 GMT
Proxy-Support: Session-Based-Authentication

---

HEAD http://home7/Server/WebService.asmx/UploadFile HTTP/1.1
Authorization: Negotiate YHgGBisGAQUFAqBuMGygMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHqI4BDZOVExNU1NQ...
Host: home7

---

HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: Negotiate oYGmMIGjoAMKAQGhDAYKKwYBBAGCNwICCqKBjQSBik5UTE1TU1AAAgAAAAoACgA4AAAAFcKK4owppiVY+cIjQMsrAAAAAABIAEgAQgAAAAYBsR0AAAAPSABPAE0A...
Date: Tue, 15 May 2012 21:34:26 GMT
Proxy-Support: Session-Based-Authentication

---

HEAD http://home7/Server/WebService.asmx/UploadFile HTTP/1.1
Authorization: Negotiate oXcwdaADCgEBoloEWE5UTE1TU1AAAwAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAABXCiOIGAbEdAAAAD40MPz+laiptu...
Host: home7

---

HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 5256
Content-Type: text/html; charset=utf-8
Server: UltiDev Web Server Pro (3.0.0.16) Microsoft-HTTPAPI/2.0
X-AspNet-Version: 4.0.30319
WWW-Authenticate: oRswGaADCgEAoxIEEAEAAABDh+CIwTbjqQAAAAA=
Date: Tue, 15 May 2012 21:34:26 GMT

---

Eventually I've found a simple workaround: do not user "HEAD" request, but rather use "POST" (or "GET") with UnsafeAuthenticatedConnectionSharing = true.

Thanks for your quick response!

Hello, Oleg.

Here's a small update:

- We have re-tested the test project on a non-domain machine and 400 problem went away, and the application simply worked. Test project always had "POST" method, not HEAD, and has no UnsafeAuthenticatedConnectionSharing=true. It works fine, starts with two expected auth challenge responses from http.sys and third attempt going through. UnsafeAuthenticatedConnectionSharing=true will ensure that 401 challenges will not precede every request. But the bottom line is that test project you sent us worked for us in all tests. If you could still send us a test project to repro the issue with HEAD, that worked on IIS/WebDev with NTLM but not with UWS, we would appreciate your help with improving UWS.

- Build 16 you are using has a pretty nasty bug making it impossible in some cases to set multiple response headers of the same kind (like Set-Cookie). Although it does not look like it played a role in this issue, we still recommend getting the latest build.

Thank you much for detailed issue submission!

Best regards,
UltiDev Team.