Josh Wieder

Classic ASP works a bit differently then the .NET framework. To many administrators (like me), the subtle differences can be a bit of a nuisance. Tasks that are performed daily with .NET are just different enough with Classic ASP to force an admin to consult the Google Brain. If that's why you're here - don't feel bad and don't worry. We have all been there, and we have a solution for you. This post will focus on error display using IIS7 and Classic ASP. In .NET, this is a simple matter of configuring the customErrors imperative in the web.config file. With Classic ASP, a bit of work needs fixin' within IIS Manager. Launch IIS Manager (Start --> Run --> inetmgr). Highlight your server name onthe left-hand menu. Then on the right side, you should be looking under the IIS heading. Select Debugging Properties and set the "Send Errors to Browser" setting to true. Back under the IIS heading, select Error Paged and then the 500 Error Page.Select Edit Fea

So its been about 5 months since the IETF released the RFC 6455 proposal for websockets: http://tools.ietf.org/html/rfc6455 The websocket API is a protocol that allows for the bidirectional transfer of http/https data. This breaks down to a single initial handshake and then autonomous communication from both the server and client concurrently. With it comes a significant performance improvement (as only one handshake is needed, and client-side implementation gets much simpler) and a number of practical applications - I always think chat clients, but the applications are endless for web driven applications that require real time data transfer (HTML5 games that don't suck!) Its no secret that websockets will not work with a standard IIS7 implementation. Http.sys is a greedy bugger, and gobbles up all connections listening on port 80. Even with WCF, there is no formally recognized workaround besides "wait for 8" and the native websocket/SOAP functionality that it