W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1999

RE: Delete, Move, and Copy for References (Yaron's Issue #9)

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Mon, 1 Mar 1999 09:54:02 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E801BA4D13@x-wb-0128-nt8.wrc.xerox.com>
To: "'gclemm@atria.com'" <gclemm@atria.com>, yarong@microsoft.com
Cc: w3c-dist-auth@w3.org
The current collections spec says what you recommend: GET, HEAD, PROPFIND (I
assume those are the methods you might use to find the size of the resource)
get passed through to the target by default, and can be made to apply to the
reference by using No-Passthrough.


> -----Original Message-----
> From: gclemm@atria.com [mailto:gclemm@atria.com]
> Sent: Saturday, February 27, 1999 11:03 AM
> To: yarong@microsoft.com
> Cc: w3c-dist-auth@w3.org
> Subject: RE: Delete, Move, and Copy for References (Yaron's Issue #9)
> 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
Received on Monday, 1 March 1999 09:50:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:16 UTC