From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] hget From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 30 Mar 2004 00:22:41 +0100 Topicbox-Message-UUID: 46765a40-eacd-11e9-9e20-41e7f4b1d025 > unfortunately, it is not in fact guaranteed in practice that the http > message will have a header that includes a byte count (at all) or an > accurate one (if that). hence some of the heuristics. agreed, but i'd still maintain that it's not good for it to potentially produce the same data multiple times on an output stream. in fact it seems to me it should never do this, and doesn't need to: there's a known point up to which it has good data. if it has to refetch data before this point it can just discard it. getting partial parts of a file there's always a danger that you're a getting a partial part of a different file, but that case is wrong for the current hget too (if the new file is shorter you'll get a part of the older one tacked on to the end, as it doesn't truncate the file when it seeks to 0). so maybe that's the right solution: avoid all seeks always; they're never necessary. no extra options, and the code should be straightforward.