W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2008

Re: multiget reports Re: Thoughts on relation to WebDAV

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 28 May 2008 13:21:21 +0200
Message-ID: <483D4031.2030609@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT