Random Thoughts

Azure Blobs are a scalable infrastructure to host\store files. I was working on understanding the behavior of large file uploads and downloads and create a reasonable strategy to support both scenarios in our application. Azure blob file can be downloaded using any browser or internet download manager. For a public blob the url of file would suffice, but for downloading a private blob one needs to create a url containing the Secured Access Signature . While testing downloads I realized that in case I pause and resume the download in Firefox or Chrome or any download manager the download restarts !!! I was expecting that the download should start from the place it paused. Imagine the scenario where we have uploaded half of a 2GB file and resuming the download would start over again !!! Clearly the Azure Blob storage was not supporting HTTP Range header . As it turns out the Azure blob service is not a trivial file server. It is more of a Storage Application Server. It exp...

People who come from WCF/ Web Services background and  transition to RESTish type communication infrastructure make mistakes that follow a common pattern. I have seen it with people who are new to REST and with people who have spent some time working with RESTful services. (Throughout the post where every I mention REST I mean REST over HTTP)  The common misconceptions  are Not understanding the difference between HTTP POST and GET, in fact having too little or no clue about HTTP Verbs. For most devs interaction with server involves calling a client proxy method, handling the request on server, sending a response back from server, handling the response on client. This abstraction means no one knows what happens at infrastructure level. When programming for HTTP one cannot ignore the abstraction, else we cannot take full advantage of the medium. The manifestation of the above affect is, either every call becomes a POST or every call becomes a GET. When every...

Working with ASP.Net and SilverLight in my current project i learned two important things today SL will always show generic NotFound exception for a remote call failures irrespective of what was returned from server. This limitation roots in the browser which does not pass the exception details to the SL plugin. The only way around is to always send a responses which have Fault property for the SL client to work with. ASP.Net forms authentication mechanism always redirects on 404 error and behaviour is hard to change. This becomes a problem working with SL or ASP.Net MVC clients which expect Http error code (REST clients). The workaround that i found on Stackoverflow was to thrown 403 Error Code instead of 401. This way service calls made from SL or ASP.Net MVC can return http status codes (REST endpoints) and will not cause server redirects.