IETF Logo Mail Archive

Re: Multi-GET, extreme compression?

Cyrus Daboo <cyrus@daboo.name> Sun, 17 February 2013 19:20 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D8321F8B36 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 11:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.966
X-Spam-Level:
X-Spam-Status: No, score=-7.966 tagged_above=-999 required=5 tests=[AWL=2.033, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOGaSoOUXGnq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 11:20:26 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B179021F8B35 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 11:20:26 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U79lO-000445-Mm for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Feb 2013 19:19:02 +0000
Resent-Date: Sun, 17 Feb 2013 19:19:02 +0000
Resent-Message-Id: <E1U79lO-000445-Mm@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <cyrus@daboo.name>) id 1U79lG-00043H-Qs for ietf-http-wg@listhub.w3.org; Sun, 17 Feb 2013 19:18:54 +0000
Received: from daboo.name ([173.13.55.49]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <cyrus@daboo.name>) id 1U79lG-0003hc-Be for ietf-http-wg@w3.org; Sun, 17 Feb 2013 19:18:54 +0000
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0400B3D8EC6F; Sun, 17 Feb 2013 14:18:32 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWBBVImawWU0; Sun, 17 Feb 2013 14:18:31 -0500 (EST)
Received: from [17.45.162.188] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 1E2353D8EC62; Sun, 17 Feb 2013 14:18:30 -0500 (EST)
Date: Sun, 17 Feb 2013 14:18:33 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <A6A82B6EF92590887D2A23D5@cyrus.local>
In-Reply-To: <CAMm+LwiF6EM8_aQgUm=nPS5XqaG25iRGNke_rnHTM1vTGMXdfg@mail.gmail.com>
References: <CAMm+LwiF6EM8_aQgUm=nPS5XqaG25iRGNke_rnHTM1vTGMXdfg@mail.gmail.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="995"
Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: AWL=-3.172, RP_MATCHES_RCVD=-0.556
X-W3C-Scan-Sig: lisa.w3.org 1U79lG-0003hc-Be ae71394a435e599254f4b5aecf22fede
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Multi-GET, extreme compression?
Archived-At: <http://www.w3.org/mid/A6A82B6EF92590887D2A23D5@cyrus.local>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16628
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Phillip,

--On February 16, 2013 1:01:59 PM -0500 Phillip Hallam-Baker 
<hallam@gmail.com> wrote:

> And the typical communication pattern of a browser would be:
>
>
> GET /toplevel.html
> MGET </image1.jpg /image2.jpg ...>
>
>
>
> Given this particular communication pattern which has an implicit delta
> encoding, do we really need to worry about a separate delta encoding?
>

We added a multiget REPORT to CalDAV (RFC4791) and CardDAV (RFC6352) which 
is used by clients when sync'ing a lot of resources (e.g., initial account 
setup). The one major criticism has been lack of cacheability of the 
individual resources included in the multiget.

So in your example, if one client did MGET (image1, image2) and another did 
GET (image1) then ideally the second could be returned by the cache. So 
would we expect caches to be able to "split-up" the resources in an MGET so 
it could serve them up individually for a GET, or in some other combination 
for a different MGET?

-- 
Cyrus Daboo

v2.23.0 | Report a Bug | By Email