<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Take a Number</title>
	<atom:link href="http://enthusiasm.cozy.org/archives/2007/12/take-a-number-2/feed" rel="self" type="application/rss+xml" />
	<link>http://enthusiasm.cozy.org/archives/2007/12/take-a-number-2</link>
	<description>Ben Hyde</description>
	<pubDate>Wed, 08 Oct 2008 02:59:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: epc</title>
		<link>http://enthusiasm.cozy.org/archives/2007/12/take-a-number-2#comment-96383</link>
		<dc:creator>epc</dc:creator>
		<pubDate>Mon, 10 Dec 2007 11:00:19 +0000</pubDate>
		<guid isPermaLink="false">http://enthusiasm.cozy.org/archives/2007/12/take-a-number-2/#comment-96383</guid>
		<description>I tried this once, I set up a system where the primary server responded with a Refresh header in the HTTP block (not a "meta refresh"), which had a 0-30 second delay followed by the primary URL again, polling until the load had dropped on the download server.  Then the primary would return a 302 redirect to the newly freed download server.

There were some problems with this though: although web browsers had no problems  dealing with the Refresh: header, users seem to be conditioned to download starting automatically and would either close the window or do a shift-reload, starting the queuing process over again.  Also, non-traditional browsers or command line tools didn't seem to support Refresh: in the HTTP headers and would never reload the URL.</description>
		<content:encoded><![CDATA[<p>I tried this once, I set up a system where the primary server responded with a Refresh header in the HTTP block (not a &#8220;meta refresh&#8221;), which had a 0-30 second delay followed by the primary URL again, polling until the load had dropped on the download server.  Then the primary would return a 302 redirect to the newly freed download server.</p>
<p>There were some problems with this though: although web browsers had no problems  dealing with the Refresh: header, users seem to be conditioned to download starting automatically and would either close the window or do a shift-reload, starting the queuing process over again.  Also, non-traditional browsers or command line tools didn&#8217;t seem to support Refresh: in the HTTP headers and would never reload the URL.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
