- From: Geoffrey M. Clemm <gclemm@atria.com>
- Date: Sat, 27 Feb 1999 11:02:42 -0500
- To: yarong@microsoft.com
- Cc: w3c-dist-auth@w3.org
One more point on the "space of a COPY" issue. When a downlevel client asks "what is the size of this GIF resource", and the answer came back "20 bytes" (because the resource was actually a direct reference to a GIF resource and the server is just telling it how much space the reference takes), that downlevel client will probably be a bit surprised when it allocates a read-buffer based on this size answer, and then tries to GET that GIF file into a 20 byte buffer. Similarly, if that client asks "how big is this collection of GIF resources", and the answer comes back "200 bytes" (because it is just 10 references to GIF resources), the allocation of a 200 byte buffer to store that GIF collection won't work much better. So I will argue that a "size" query, like all other queries in the context of references, should take a NO-PASSTHROUGH header (so an uplevel client can ask for both flavors of "size"), but that the default "size" query should be passed through to the targets, and then a downlevel client would be surprised if Yaron's copy did not take 6 gig! Cheers, Geoff > From: Yaron Goland <yarong@microsoft.com> > > What really scares me is a scenario where I have a directory filled with > references but I'm using an RFC 2518 client. If I copy the directory I will > go from a directory that took up a few kilobytes (just to record the > references) to one of any random and potentially huge size. The source > directory ate 30Kb and the destination eats up 6 Gig. I would call that > surprising.
Received on Saturday, 27 February 1999 11:02:46 UTC