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

Re: multiget reports Re: Thoughts on relation to WebDAV

From: Helge Hess <helge.hess@opengroupware.org>
Date: Wed, 28 May 2008 13:08:36 +0200
Message-Id: <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org>
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  

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


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


HTTP/1.1 201 Created
content-length: 0
content-type: text/calendar; charset=utf-8
content-location: /calendar/999.ics
location: /calendar/999.ics


Makes sense? I admit, its very similiar to pipelining, but much easier  
to implement using existing infrastructure.

Helge Hess
Received on Wednesday, 28 May 2008 11:09:11 UTC

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