Re: multiget reports Re: Thoughts on relation to WebDAV

Julian Reschke <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.