Thursday, January 26, 2006

Pondscum and Microsoft, two things we'll never be without

I can't be the only one to link the two...
Both can be disgusting words that contort the very marrow of your being while providing global benefit in their own way.

Technically, I can't truly justify the comparison, never having to really study pondscum.

So, once again, I'm here because of some undocumented feature of Microsoft's 'New, faster, better!' technology broke the previous 'New, faster, better!' code. I can't quite figure out why I only seem to run into problems when I have a Microsoft program talking on a Microsoft OS to a Microsoft Client.

It's late October, and we decide it would be 'great' to upgrade all of our servers to Windows 2003 Native mode, especially with VS .Net 2005 vapourware finally solidifying.

We've already tested and read 'all there is to know' and ran every compatibility tool they had and knew it would be smooth sailing. The only tedious processes would be our Exchange Server (since we're truly recreating every user) and our Corporate Intranet Site (IIS 5.0 on Win 2k Server), which was an amalgamation of ASP, JSP and ASP.NET 1.1 applications.

Everything goes mostly great, mail's up, web site is running IIS 6 with compression and is simply screaming on our new Cisco switches with our T.
Life is good.

Unless you attempt to download a file from our download application using Internet Explorer...

Suddenly MSIE has no idea what to do with the file I'm sending, and provides a 'Save As' dialog box as 'download.aspx' no matter what file is requested.
Naturally I assume it must be my fault, and I upgrade the codebase (that's re-write to all the non-geeks out there) to C# 2.0. The new enhancements are truly beautiful and I'm duly impressed. My code now comes up with that same bogus 'download.aspx' quicker and more efficiently that I ever thought possible!

Naturally I assume it must be my fault, so I revisit the RFC protocol and standards archives to see if I'm just forgetting what HTTP headers are. Sadly, I was correct. However, I figure MS is just looking for a very specific way of recieving the file since they have all these new overloaded methods.
The next week is spent trying variations of Response.WriteFile, Response.TransmitFile, Response.BinaryWrite, Response.AdNasuem.
Each variation puts out the same end result. Finally I am force to conclude that there is something wrong with this picture.
So I deploy my 'Works on my XP box' download application to another Windows 2003 server and it works! The only difference is that the other server isn't using compression.

It turns out, that Microsoft Internet Explorer literally ignores all information regarding the size, type and how you would like to handle the file and 'sniffs' or 'guesses' what the file is. MSIE Mime Type Detection

So basically, I never really had to do all that coding 2 years ago because MS was just tossing it away, then arriving at the same conclusion. But when the Microsoft Supplied compression (encoding: gzip as per MS documentation) is enabled, MS tosses away my supplied information, fails to guess the type (zipping changes the file signiture), tries to issue another request (which fails because you can't resend an original request) and then has no other information avaible to it but the name of the file that started this whole thing, which happens to be a ASP.Net script called 'Download.aspx'.

I console myself blog / forum surfing after a bit because MSIE 'sniffing' has been a larger burden on many people since a long F'n time ago. In Windows XP SP2 they provided a way of disabling the 'feature'. (Yeah!!!)
All I need to do to take advantage is use C++ or change registry settings in every employee's PC / Laptop worldwide!


So, how did "Force offscreen compositing even under Terminal Server (Requires restart)" make it as a simple checkbox option, but 'stop playing "Let me guess what type of file your sending" and just assume that the 5 k ASCII stream labeled 'text/plain' with a file name of readme.txt is... a TEXT FILE!"

Alternately, since you're sniffing, you could check the 'Content-encoding' header value, which clearly states gzip encoding, and take that into consideration to guess right.

I suppose the reason I'm particullarly miffed is not that MS choose to ignore yet another globally accepted standard, but the reason they claim to do it. Sniffing is 'designed to prevent malicous people form calling an evil file something innocent like .txt and trying to force a user into executing it.
A noble goal if it were accurate. However, if you go to a web page, any web page, view source and save it as with a .txt extension, then view it in internet explorer, guess what? Even with XP SP2, it should diplay as harmless text, but no, MSIE checks the file and says 'hey, look! HTML tags, I bet I can make this look like a web page' and voila!

I'm going to spew something horrid if I have to write a single line of C++ to fix what is not broken in every browser in the world but MSIE. Something putrid.. something.. like...


No comments: