Re: multiget reports Re: Thoughts on relation to WebDAV

Helge Hess <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <[email protected]>
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/
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.