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

Re: Multi-GET, extreme compression?

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Sat, 16 Feb 2013 10:22:58 -0800
Message-ID: <CAA4WUYjz_Em7sYcYpU162Uo6CoshjdK_78_NTCubWS7Vp+_PPA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
This sounds very similar to Willy's proposal:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0324.html
Willy and I go back and forth about it:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0333.html


On Sat, Feb 16, 2013 at 10:01 AM, 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?
>
>
> --
> Website: http://hallambaker.com/
>
Received on Saturday, 16 February 2013 18:23:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 16 February 2013 18:23:31 GMT