On Sun, Feb 17, 2013 at 5:38 PM, Helge Hess <helge.hess@opengroupware.org>wrote: > On Feb 17, 2013, at 5:30 PM, William Chan (陈智昌) <willchan@chromium.org> > 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 > >
Received on Monday, 18 February 2013 01:53:05 UTC