Err, pressed Enter by mistake!

The issue that we're facing in Gecko is that we want to construct a Request object in the child process and hand it off to the SW without going to the parent process.  In order to construct some HTTP headers such as Cookies, we do need to run code in the parent process, which means that we need to do this work before we can create a Request object, which will have unacceptable perf implications for us.  I think we need to make at least get, getAll and has on Headers asynchronous.

So right now the Headers object is pretty dumb.  It is simply a multi-map that has a type of "request", "response", etc.  It doesn't need to know what underlying request its actually tied to.  This is pretty simple and straightforward.

For example, its easy to reason about how one would take the headers from the original SW request and then create a new request using that same Headers object.  If the Headers we tied behind the scenes to the underlying request, that would seem to make this more complex.

As an alternative, could we make the Headers attachment to Request asynchronous instead.  So replace:

  interface Request {
    readonly attribute Headers headers;
  };

With:

  interface Request {
    Promise<Headers> getHeaders();
  };

Or if comment 2 is not possible, perhaps allowing append() and set() to take Promises would keep things simple.  Headers would still be a multi-map, but on that can store async values.

Wait, did you read the specification Ehsan? Network-level headers such as cookies are added last-minute. They are not normally in the object. Assuming you're talking about requests.

Yeah, it seems like the cross-compartment concern was not justified since there is no cross-compartment interaction per the specification.

Yep, Anne's right!