- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 28 May 2008 13:21:21 +0200
- To: Helge Hess <helge.hess@opengroupware.org>
- CC: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Helge Hess wrote: > > 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 The responses to REPORT *could* be made cacheable, if we adopt one of the proposals outlined in <http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-01.html>. BR, Julian
Received on Wednesday, 28 May 2008 11:22:08 UTC