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 >>> >>> >
- Multi-GET, extreme compression? Phillip Hallam-Baker
- Re: Multi-GET, extreme compression? William Chan (陈智昌)
- Re: Multi-GET, extreme compression? Cyrus Daboo
- Re: Multi-GET, extreme compression? Helge Heß
- Re: Multi-GET, extreme compression? James M Snell
- Re: Multi-GET, extreme compression? Roberto Peon
- Re: Multi-GET, extreme compression? Dr Robert Mattson
- Re: Multi-GET, extreme compression? James M Snell
- Re: Multi-GET, extreme compression? Bjoern Hoehrmann
- Re: Multi-GET, extreme compression? Dr Robert Mattson
- Re: Multi-GET, extreme compression? Helge Hess
- Re: Multi-GET, extreme compression? William Chan (陈智昌)
- Re: Multi-GET, extreme compression? Helge Hess
- Re: Multi-GET, extreme compression? William Chan (陈智昌)
- Re: Multi-GET, extreme compression? Helge Hess
- Re: Multi-GET, extreme compression? Mark Nottingham
- Re: Multi-GET, extreme compression? Helge Hess
- Re: Multi-GET, extreme compression? James M Snell
- Re: Multi-GET, extreme compression? James M Snell
- Re: Multi-GET, extreme compression? Phillip Hallam-Baker
- Re: Multi-GET, extreme compression? William Chan (陈智昌)
- Re: Multi-GET, extreme compression? Willy Tarreau
- Re: Multi-GET, extreme compression? Patrick McManus
- Re: Multi-GET, extreme compression? Phillip Hallam-Baker
- Re: Multi-GET, extreme compression? Brian Pane
- Re: Multi-GET, extreme compression? Mark Baker
- Re: Multi-GET, extreme compression? Nico Williams
- Re: Multi-GET, extreme compression? Nico Williams
- Re: Multi-GET, extreme compression? Mark Nottingham
- Re: Multi-GET, extreme compression? Nico Williams
- Re: Multi-GET, extreme compression? Mark Nottingham
- Re: Multi-GET, extreme compression? Nico Williams
- Re: Multi-GET, extreme compression? Nicolas Mailhot
- Re: Multi-GET, extreme compression? Julian Reschke
- Re: Multi-GET, extreme compression? Nicolas Mailhot
- Re: Multi-GET, extreme compression? James M Snell
- Re: Multi-GET, extreme compression? Julian Reschke
- Re: Multi-GET, extreme compression? Julian Reschke
- Re: Multi-GET, extreme compression? Nicolas Mailhot
- Re: Multi-GET, extreme compression? Julian Reschke
- Re: Multi-GET, extreme compression? Phillip Hallam-Baker