<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Todays bug is...</title><link>http://blogs.msdn.com/sjarawan/archive/2005/03/08/389690.aspx</link><description>Today I'm thinking about a recent bug we have for file attachments for work item tracking in Team Foundation System. We are using HTTP Post with multi-mime parts to upload a file to the server. The problem is when a file size is larger then the maximum</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Todays bug is...</title><link>http://blogs.msdn.com/sjarawan/archive/2005/03/08/389690.aspx#389806</link><pubDate>Wed, 09 Mar 2005 00:28:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:389806</guid><dc:creator>Jason Coyne</dc:creator><description>From my experience, IIS does not react well to uploads of even a few hundred megs in .net, let alone a full gig. My understanding is that this is because .net laods the entire stream into memory, and doesnt chunk it off into disk as the file is uploaded.  This then creates the market for products such as SAFileUp.&lt;br&gt;&lt;br&gt;Wihtout SA Fileup, I get my web server continually restarting the ASPNet worker process, because too much ram is being used by .net (leak protection?)&lt;br&gt;&lt;br&gt;How will Team Foundation address the issue of large files in this context?</description></item><item><title>re: Todays bug is...</title><link>http://blogs.msdn.com/sjarawan/archive/2005/03/08/389690.aspx#390155</link><pubDate>Wed, 09 Mar 2005 10:32:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:390155</guid><dc:creator>Anon</dc:creator><description>Isn't there a better/more scalable protocol  than HTTP Post to transfer such large amounts of data, like WS-Attachments or something? Heck, why not FTP? It's not sexy, but it's mature.&lt;br&gt;&lt;br&gt;Also, how about doing it in chunks that are smaller than the request size limit? The downside is that the operation probably wouldn't be atomic, but that would only be for the very large files that are over the limit (and the user would otherwise be out of luck), and the user could be shown an appropriate disclaimer dialog in that case.</description></item><item><title>re: Todays bug is...</title><link>http://blogs.msdn.com/sjarawan/archive/2005/03/08/389690.aspx#390846</link><pubDate>Wed, 09 Mar 2005 20:30:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:390846</guid><dc:creator>Sam Jarawan</dc:creator><description>There definitely are better ways to upload large amounts of data but since we don't (at least not yet) have requirements to support gigabyte files we chose the HTTP Post method.  One of the advantages we have for downloading attachments via HTTP Get is we pass back the download file to IE and let it perform security on the file.  That way we get the friendly IE dialog that asks whether you want to open or save the file, so that saves us from reimplementing this.  If we chunk the file then we'd have to put it back together ourselves and then we couldn't leverage IE for opening/saving the file.&lt;br&gt;&lt;br&gt;If our PMs come back and say customers NEED support for very large attachments then we'll revisit this and probably do some sort of chunking solution.&lt;br&gt;&lt;br&gt;Thanks for you comments.&lt;br&gt;&lt;br&gt;Sam&lt;br&gt;&lt;br&gt;&lt;br&gt;This posting is provided &amp;quot;AS IS&amp;quot; with no warranties, and confers no rights.</description></item></channel></rss>