[webkit-dev] Loading from shared workers (shadow documents?)

[Drew Wilson]

Hi all,
I'm about to work on adding network access support to shared workers. To
refresh your memory, shared workers can outlive any specific document object
- they exit when the last referring document exits.

Current dedicated workers just proxy all network operations over to their
associated Document object. If the Document is closed prematurely, then the
network operation is aborted and an error is returned to the worker, which
is fine because the Worker is exiting anyway.

For shared workers we can't just proxy network operations over to an
arbitrary parent document, because the user may choose to close that
document in mid-load yielding an inappropriate error response to the user.
We have a few options:

1) If a document closes mid-load, just return an error to the worker. So
treat this case like Just Another Network Hiccup.

2) If a document closes mid-load, just retry the network access on another
parent document. I'm not certain that this is acceptable from a
spec-compliance standpoint (the server might end up seeing multiple network
requests even though from the client stand point only one was issued).

3) Don't let documents fully go away while there's outstanding worker
network access. For a long-lived hanging get, this seems like it might keep
a document around (in hidden state) for a long time, and I'm not sure what
the ramifications are of that. Also, there's the issue of how to deal with
things like HTTP auth from hidden documents (although HTTP auth is
problematic for shared workers in general as it's kind of arbitrary which
window the auth UI appears under).

4) Create a new "shadow document" for the worker that it uses to satisfy all
of its loading requests. This is what Chromium does for all its worker
network access currently. This is the most robust solution, although I'm
still not certain how HTTP auth would be handled in this case).

I'm leaning towards #1 in the short-term, but I'd like to get feedback about
what our long-term approach should be.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090807/d279a724/attachment.html>