Changes in the Workspaces releases area

RE: Changes in the Workspaces releases area

Signs on the Sand — Tue, 16 Mar 2004 09:42:00 GMT

Hey, good news about GotDotNet Workspaces again! Changes on the releases section scheduled for tomorrow include: per-release download count (AT LAST!!!), no more zero-byte/corrupt downloads (I hope), no more Passport sign-in for downloads (great), off-site hosting of releases (cool). Really sweet. [Via Andy Oakley]...

re: Changes in the Workspaces releases area

Omar Shahine — Wed, 17 Mar 2004 01:53:00 GMT

Dude, the recent checkins feature is sweet! With XML feed too! No more need for checkin mail! wohoo.

re: Changes in the Workspaces releases area

Matt Johnson — Mon, 31 May 2004 18:33:00 GMT

Could you perhaps explain how you worked around 308090? It is being a pain for me and nobody seems to have a good answer.

re: Changes in the Workspaces releases area

Andy Oakley — Tue, 01 Jun 2004 17:33:00 GMT

We ended up creating an implementation of IHttpHandler.

The handler, located in its own directory, is set to handle all incoming requests:

<httpHandlers>
<add verb="*" path="DownloadRelease" type="GotDotNet.Community.Workspace.ReleaseDownloadHandler, ReleaseDownloadHandler" />
</httpHandlers>

In the implementation, the ProcessRequest method handles the spitting out of the bytes to context.Response. They key difference in this approach is that you can set the incoming link to a URL that appears to be a ZIP file (.../releases/download/abc/myfile.zip say) and use context.Request.PathInfo.Split to extract the parts you need (abc, for the Workspace, myfile.zip for the file). It's generally the Content-Disposition header part that confuses IE and exacerbates 308090 and this solution hides all of the underlying dynamic generation from the browser.

Sadly, there remain a few client scenarios where the problem persists even with this approach, but it seems to work for the vast majority.

Hope that helps.