- From: Helge Hess <helge.hess@opengroupware.org>
- Date: Wed, 28 May 2008 13:08:36 +0200
- To: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
On 28.05.2008, at 12:05, Julian Reschke wrote: > Helge Hess wrote: >> Could you elaborate? An MGET capable cache could still disassemble >> the MGET and serve the individual resources from its cache (which >> is in fact why I would prefer a real MGET instead of a REPORT). It >> would really just be a nested request. > OK, that would work, but will be tricky to deploy. *Existing* caches > will not know how to do it. Si. But they don't know how to deal with MKCOL or REPORT either, so I think thats not really relevant to my question :-) Point is: MGET method would be cachable according to the rules which apply to the embedded requests. So, does it make sense to do a 'mget-ext' proposal? What about caldav/ carddav vendors, would you implement it? Cyrus? Maybe this should actually be a 'BATCH' method, not an 'MGET' (GET specific). ---snip:rq--- BATCH /calendar HTTP/1.1 content-type: x-http/batch-rq content-len: xyz accept-encoding: gzip GET /calendar/123.ics accept: text/calendar; charset-utf-8 if-none-match: "myetag" content-length: 0 GET 345.ics # allow relative URLs? would be nice accept: text/calendar; charset-utf-8 if-none-match: "myetag" content-length: 0 POST /calendar HTTP/1.0 content-type: text/calendar; charset=utf-8 content-length: uujk BEGIN:VCALENDAR ... ---snap--- ---snip:res--- HTTP/1.1 200 OK content-type: x-http/batch-res content-len: xyz content-encoding: gzip # the whole batch could be encoded, w/o TE HTTP/1.1 304 Not Modified content-length: 0 content-location: /calendar/123.ics HTTP/1.1 200 OK content-length: opq content-type: text/calendar; charset=utf-8 content-location: /calendar/345.ics BEGIN:VCALENDAR ... HTTP/1.1 201 Created content-length: 0 content-type: text/calendar; charset=utf-8 content-location: /calendar/999.ics location: /calendar/999.ics ---snap--- Makes sense? I admit, its very similiar to pipelining, but much easier to implement using existing infrastructure. Thanks, Helge -- Helge Hess http://www.helgehess.eu/
Received on Wednesday, 28 May 2008 11:09:11 UTC