oob for multiple objects

[DanielLindstrm]

It could be useful if the primary server would be able to send information about multiple objects in the body of the out-of-band encoded message. i.e. also for files not yet requested. That way the browser does not need to send any unnecessary requests for objects that the primary server is going to send out-of-band later.

However, that would mean sending meta data about the objects in the body instead of in headers.
An example of such a response could be something like this:

Response:

HTTP/1.1 200 OK
Date: Wed, 26 Aug 2015 17:06:00 GMT
Content-Type: application/json
Content-Encoding: out-of-band
Encryption-Key: keyid=key1; key=very_secret_key

[
  {
    "obj": "/path/file1.jpg",
    "oob-link": "https://new_path/993ufjf8-f19jf-13f",
    "Content-Type": "image/jpg",
    "Cache-Control": "max-age:5000"
  },
  {
    "obj": "/path/style.css",
    "oob-link": "https://new_path/j39j3-jf83hf-hkjfj3",
    "Content-Type": "text/css",
    "Cache-Control": "max-age:1000"
  },
  {
    "obj": "/path/a_movie.mp4",
    "oob-link": "https://new_path/mm429d-29jd2-ddj2f",
    "Content-Type": "video/mp4",
    "Cache-Control": "max-age:10000"
  }
]

[reschke]

Do you envision that as a separate content coding?

[DanielLindstrm]

I'm not sure I understand the question. Do you mean something else than "out-of-bands"?

[reschke]

Ah :-) The encoding defined in the draft is called "out-of-band" (no trailing "s"), thus my confusion.

[DanielLindstrm]

Ah, I see. That extra 's' was a mistake. :-)
I have removed it from the first post.

[gaperik]

And just for the record- we need to take into account security risks that may arise of the origin server decides to provide information for more objects than the one explicitly requested, :-).

[reschke]

1. This feature seems to be somehow isomorphic to HTTP/2 server push. That is, if the communication between client and origin server uses HTTP/2, we don't need this feature. Is there any reason to believe that we just can't assume that HTTP/2 will be used?

2. If we decide that this is needed for HTTP/1.1 as well, we need to consider the security implications (which should be identical to those in http://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.10.4), and we need to figure out where the put the information. Extending the OOB payload with information about other resources looks a bit like stretching the concept behind OOB too far. An alternative might be another content coding that would enable PUSH-like features (potentially just re-using frame formats from HTTP/2). That encoding could then be combined with "ouf-of-band".

[reschke]

re 1) I hear that the reason we currently can't rely on server push is that we'd like to be able to implement the client side as a service worker, and these currently do not have access to the cache.

[DanielLindstrm]

yes.. but I don't think I understand why it would not be needed if we had have server push. I can see that server push could be a way to distribute the map to the client.. but I get the feeling that it would be faster to distribute the map to the client via the first response sent to it from the origin.

If server is used I guess that means that the server push needs to happen before the client have already downloaded the content it needs for the site.

[gaperik]

Correct. A BC mechanism built into the UA is of course very desirable but a
SW based solution has many attractive advantages as well. Preferably, both
type of endpoints should be supported by the protocol extensions.

2015-09-11 13:14 GMT+02:00 Julian Reschke notifications@github.com:

re 1) I hear that the reason we currently can't rely on server push is
that we'd like to be able to implement the client side as a service worker,
and these currently do not have access to the cache.

—
Reply to this email directly or view it on GitHub
#5 (comment).

[gaperik]

If the cache map is big it also could be pushed in steps. It would also be
a way to update the cache-map, be it in the SW javascript or in the browser
user agent. But we're not quite there yet where we can see a clear need for
it. Other stuff more urgent to solve.

2015-09-11 14:10 GMT+02:00 DanielLindstrm notifications@github.com:

yes.. but I don't think I understand why it would not be needed if we had
have server push. I can see that server push could be a way to distribute
the map to the client.. but I get the feeling that it would be faster to
distribute the map to the client via the first response sent to it from the
origin.

If server is used I guess that means that the server push needs to happen
before the client have already downloaded the content it needs for the site.

—
Reply to this email directly or view it on GitHub
#5 (comment).