Re: Multi-GET, extreme compression?

James M Snell <jasnell@gmail.com> Mon, 18 February 2013 00:59 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 09E4A21F8A52 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 16:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.193
X-Spam-Level:
X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 8fAQaWsEr9vW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 16:59:51 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0F21F8A48 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 16:59:51 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7F4X-00061X-4f for ietf-http-wg-dist@listhub.w3.org; Mon, 18 Feb 2013 00:59:09 +0000
Resent-Date: Mon, 18 Feb 2013 00:59:09 +0000
Resent-Message-Id: <E1U7F4X-00061X-4f@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1U7F4M-00060M-Ge for ietf-http-wg@listhub.w3.org; Mon, 18 Feb 2013 00:58:58 +0000
Received: from mail-oa0-f50.google.com ([209.85.219.50]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1U7F4L-0005AL-0p for ietf-http-wg@w3.org; Mon, 18 Feb 2013 00:58:58 +0000
Received: by mail-oa0-f50.google.com with SMTP id l20so5270199oag.23 for <ietf-http-wg@w3.org>; Sun, 17 Feb 2013 16:58:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3Y8Ek9mttALoi24ru9znSTotyxRcNHxGGdjCML9QRWY=; b=tku2DsF0q+HJenfdZWhzd0yVGKfK/vQgeOpTZX0DCgZ+oRaarJJvMkSwg752gVjMoa SKoyLd5R4Tess5NCQDj+Qja+SOlgB3E30y+b/VxpSAM3CcYJqads640PaEPKuMtENkys sj3NgkGMLLJylWeXZI/hiCzjSdn5Mdd9+Z3UyM4XPajcX3g83ALZngYegDhoxx94LGV9 P6tEdCn1x8+v3h3VbNtDZav6xO+Ff40SOZ/kKvDZyzOKwfBLURrYWLd4mD59rsl8odem 6D0RkCi158aBzxt5L2FHgFtwbVoT7ZwFk/6vxeSZlCV5ijXIf82bmcJ1eTlrPmuPznp1 kMtg==
X-Received: by 10.182.245.72 with SMTP id xm8mr5396439obc.1.1361149111094; Sun, 17 Feb 2013 16:58:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.23.193 with HTTP; Sun, 17 Feb 2013 16:58:11 -0800 (PST)
In-Reply-To: <CAP+FsNeWDBTBYJ0P-URbO5avbUno5etKid10RM+dRwDWAUys2w@mail.gmail.com>
References: <CAMm+LwiF6EM8_aQgUm=nPS5XqaG25iRGNke_rnHTM1vTGMXdfg@mail.gmail.com> <A6A82B6EF92590887D2A23D5@cyrus.local> <D9118B58-F53F-4F75-8292-2B990172E234@opengroupware.org> <CABP7RbcX2OqttZuYeuYxhyOgE_ax0M67L1ywPy_VDpW1upM69Q@mail.gmail.com> <CAP+FsNeWDBTBYJ0P-URbO5avbUno5etKid10RM+dRwDWAUys2w@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Sun, 17 Feb 2013 16:58:11 -0800
Message-ID: <CABP7RbfVvZnYPPsRvzmC0BtCiPBxQmYXHTRKtq8XE7Z2wY2EfA@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Helge Heß <helge.hess@opengroupware.org>, HTTP Working Group <ietf-http-wg@w3.org>, Phillip Hallam-Baker <hallam@gmail.com>, Cyrus Daboo <cyrus@daboo.name>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.50; envelope-from=jasnell@gmail.com; helo=mail-oa0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.684, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U7F4L-0005AL-0p 94c981d4bda8da7a82c90e1c5ca74511
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Multi-GET, extreme compression?
Archived-At: <http://www.w3.org/mid/CABP7RbfVvZnYPPsRvzmC0BtCiPBxQmYXHTRKtq8XE7Z2wY2EfA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16641
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>

A requester does not necessarily need to know everything they are
getting in advance.

That is, assume that a server defines a set of N resources and assigns
that set a singular url that represents the entire collection. When I
do..

  MGET /resource/set HTTP/2.0

The server responds by opening N server-push response streams back to
the client, each associated with the original MGET. Each would have
it's own Content-Location and Cache-Control mechanisms allowing
intermediate caches to still do the right thing. The client does not
necessarily know what all it is getting from the server in advance but
knows it needs to be prepared to handle multiple items.

Alternatively, the MGET could include multiple individual URLs, in
which case it still actually behaves the same way. The only difference
is that the client has a better understanding of exactly what it's
wanting to retrieve.

example:

MGET /assets/*.js HTTP/2.0   --> Get all the javascript files
MGET /assets/*.png HTTP/2.0  --> Get all the image files

If the cache is able to keep track of exactly which resources were
pushed in response to the MGET, then caches could keep right on doing
the right thing.

Since the resources are sent via server push, the server is
responsible for determining the priority for which resources get sent.

Yes, largely theoretical and easily abused for sure. But ought to at
least be something worth investigating.

- James

On Sun, Feb 17, 2013 at 3:19 PM, Roberto Peon <grmocg@gmail.com> wrote:
> MGET (or whatever batch request) implies you know all of what you're
> requesting when you're requesting it, which is rarely the case.
> As a result, my guess is that this won't solve the prioritization issue for
> the browser.
> -=R
>
>
> On Sun, Feb 17, 2013 at 3:07 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> An mget that leverages server push in http/2 and individual cacheable
>> response streams would be very interesting and could address at least some
>> of the prioritization issues.
>>
>> On Feb 17, 2013 12:17 PM, "Helge Heß" <helge.hess@opengroupware.org>
>> wrote:
>>>
>>> On Feb 17, 2013, at 11:18 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
>>> > 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.
>>>
>>> The other major criticisms being:
>>> a) content needs to be XML encoded
>>> b) only allows for GETs, not for other operations
>>>
>>> I'd also like to see a generic, HTTP-level BATCH request. Please lets not
>>> do 'just' an MGET.
>>>
>>> hh
>>>
>>>
>