Re: Multi-GET, extreme compression?

[William Chan (陈智昌) <[e-mail]>]

On Sun, Feb 17, 2013 at 5:38 PM, Helge Hess <[e-mail]>wrote:

> On Feb 17, 2013, at 5:30 PM, William Chan (陈智昌) <[e-mail]>
> wrote:
> > I'm having difficulty grokking this proposal. Can you describe more
> clearly how this would work with the web platform? Specifically, what kind
> of markup in a HTML document should cause a browser to use a MGET for a
> resource set as you describe it.
>
> ? e.g. <img>, <script>, CSS links etc.
>

I'm confused. We issue individual GETs for the individual resource URLs.
How do we know to combine those individual resources into this magical
/resource/set path?

Furthermore, as I previously linked to in the very first reply to the
thread, when we discussed MGET previously, I highlighted how the browser
incrementally parses the document and sends GETs for resources as it
discovers them. Since my browser does not have a crystal ball telling it
that more resources are coming and when they are coming, the browser simply
issues GETs as soon as it can (subject to some other constraints like DNS
and available TCP sockets and some weak attempts at resource scheduling).


>
> > Also, how does this work for HTTP/1.X? Since we'll be living in a
> transitional world for awhile, I'd like to understand how this allows for
> HTTP/1.X semantics backwards compatibility.
>
> An old server would return a 405 when the BATCH comes in, then the client
> needs to switch to performing the operations individually.
>

So, you handwaved over how the client would magically transform URL1 + URL2
+ URL3 into magical example.com/resource/set. Assuming that's possible, how
do you do the reverse transformation, when a HTTP/2=>HTTP/1.X gateway needs
to translate HTTP/2 MGET requests for this /resource/set into the
individual GETs for the original URLs. And even if this is possible, how
reasonable is it to pay this roundtrip on receiving the 405? We've fought
really hard to eliminate roundtrips.


>
> hh
>
>