Multi-GET, extreme compression?

Phillip Hallam-Baker <> Sat, 16 February 2013 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1001421F89A3 for <>; Sat, 16 Feb 2013 10:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.212
X-Spam-Status: No, score=-9.212 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fp5mGHn9KU1B for <>; Sat, 16 Feb 2013 10:04:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 59CB521F899F for <>; Sat, 16 Feb 2013 10:04:23 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U6m5q-0007Lh-2u for; Sat, 16 Feb 2013 18:02:34 +0000
Resent-Date: Sat, 16 Feb 2013 18:02:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U6m5i-0007KE-Fc for; Sat, 16 Feb 2013 18:02:26 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1U6m5h-00053Z-P4 for; Sat, 16 Feb 2013 18:02:26 +0000
Received: by with SMTP id hm6so2223664wib.14 for <>; Sat, 16 Feb 2013 10:01:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=CMoAHemVqxxKke1nb16UlOOloY6g/hHojw+uXiff5yg=; b=R5Ivxv2iQVMVDrryo550VuVdgTjoZdWOaU573dT8dJQ9HI+jSYhko4kKE3ynV6z4QK 5/Hl76JhguaKw0yhrB2kld2c1+ObUptdQ7vC+ozzmiHVTIaYjXmBe7/BKspyOvy/ojEa tiFmrPt5SvEmqp7/XcxXyb0MSWq9zdOyzoLjySr0bOAEeXIcYT3TO4vD2zVWetZuttTD FgNobo5M934Q3VqwjBdumiidp+ES5OqOsx5l9dQIORKAga6/E1FO7jIo2usP8MGwqoK+ UhgHvd8fT4qXjI1F7zV1r/zZeDyg44aqauxK3KmoscvLPzU3DrrIHOix4HI/Q2xXn83a kffw==
MIME-Version: 1.0
X-Received: by with SMTP id hg3mr10032216wib.33.1361037719302; Sat, 16 Feb 2013 10:01:59 -0800 (PST)
Received: by with HTTP; Sat, 16 Feb 2013 10:01:59 -0800 (PST)
Date: Sat, 16 Feb 2013 13:01:59 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: " Group" <>
Content-Type: multipart/alternative; boundary=e89a8f3ba6e3c8f17304d5db49ac
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.754, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U6m5h-00053Z-P4 64e135242033d2613b677b4587f002d4
Subject: Multi-GET, extreme compression?
Archived-At: <>
X-Mailing-List: <> archive/latest/16621
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

HTTP 1.1 has a request/response pattern. This covers 90% of needs but means
that if the protocol is followed correctly forces a round trip delay on
each content request. Which of course leads to various browsers pushing the
envelope and pushing multiple requests out before responses have come back.

With content streams this is not necessary of course... In fact that is
pretty much the purpose of having streams.

Which suggests a need for a Multi-GET method to allow a request for a list
of content...

If we had such a method then the format would be something like

MGET <Common Headers> List <URI, Content header>

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?