Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
CVSROOT: /cvs Module name: cvsnt Changes by: arthur.barrett at march-hare.com Tue Dec 23 05:42:57 2008 On host: debiancvs.march-hare.local Directory: cvsnt/davio M FileInfo.cpp 1.20 -> 1.21 Bug Id: M FileInfoFile.cpp 1.56 -> 1.57 Bug Id: M FileInfoPlugins.cpp 1.26 -> 1.27 Bug Id: M FileInfoSoap.cpp 1.5 -> 1.6 Bug Id: M FileInfoTfs.cpp 1.1 -> 1.2 Bug Id: M FileInfoVfs.cpp 1.55 -> 1.56 Bug Id: M HttpAuth.cpp 1.23 -> 1.24 Bug Id: M HttpServerInfo.cpp 1.25 -> 1.26 Bug Id: M HttpServerInfo.h 1.16 -> 1.17 Bug Id: M HttpServerThread.cpp 1.25 -> 1.26 Bug Id: Directory: cvsnt/davio/methods M GetMethod.cpp 1.21 -> 1.22 Bug Id: Log message: I think I've finally found out why we've been having so many problems with IE7 (and possibly some of the webdav stuff too). There were two problems: 1) EVS response codes were non-decimal - ie: 401 not 401.1. IE7 (and much of MS software apparently) expects sites that accept NTLM to send 401.1 at some point. If the server never sends 401.1 then the client (IE7) wont always send POST data. 2) Even if the session is already authorised - IE7 expects that each POST will eventually send a 401.1 response back - and only once it gets the 401.1 will it send the POST data. EVS however does not 're-authenticate' sessions that have already been authenticated once. Here are the gory details: http://blogs.msdn.com/david.wang/archive/2005/12/01/HTTP-POST-Fails-for-Anonymous-Authentication.aspx So MS clients (including IE7) do not consistently send POST requests properly until a 401.1 is received, resulting in the appearance that half the 'posts' get lost. The results are rather random - every time I attach evsmanager to VS.NET to step through it works but every time I run the same debug binary without attaching it fails. But it fails only with IE7 on the same dev box - attaching via Safari, IE6 or IE7 on another box worked OK. I was tempted to give up and put it down to something odd - but it was a little TOO consistent so I went digging. I suspect that since the above article links to a MS knowledge base article explaining how to turn this optimisation off that perhaps when the debugger is running IE automatically doesn't 'optimise' - similarly different clients and versions of windows will or wont optimise at certain times. That's the only explanation that tallies with my results. So what I've done is: 1. Change CHttpServerInfo to use an evs::string based responsecode internally 2. Add an overloaded CHttpServerInfo::setResponse() method to set response code as string (or size_t) 3. Altered CHttpServerInfo::setResponse() to use the 401.1 and 401.2 responses (this the only place that uses string responses) 4. Modified CHttpServerInfo::Authorize() so that if the content-length is zero that it returns a nasty 411 error The following changes are probably not STRICTLY necessary provided you've cleaned your cache and rebooted, but I wanted to be darn sure I'd not have to debug this again, so I modified: 5. CHttpServerInfo::setResponse() so that if it is a POST request and zero content-length that it fails as 401.1 6. CFileInfo::Create() so that even if SessionInfo is good, that if it is a POST with zero content to call CHttpServerInfo::Authorize()