W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Multi-GET, extreme compression?

From: Nico Williams <nico@cryptonector.com>
Date: Mon, 18 Feb 2013 22:26:06 -0600
Message-ID: <CAK3OfOhBe8UdzqvNaA+pb+e=TZytsQQfp1S8pH2N_3GUk2mUgw@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Sat, Feb 16, 2013 at 12:01 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> 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?

The problem here is that the user-agent needs to get the top-level
resource first, then it will know the names of the other resources.
We can probably do better.
Received on Tuesday, 19 February 2013 04:26:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 February 2013 04:26:31 GMT