The Vary header may contain invalid header name values. We should just
ignore such values as opposed to propagating them to the caller. Before
this patch, attempts to add a request with such a Vary header for example
would fail, since the internal QueryCache() call when executing the
CachePutAllAction would fail.
The Vary header may include one or more HTTP header field names, so we
need to extract those names here, similar to the way that the
nsHttpChannel::ResponseWouldVary() function consumes the Vary header.
InternalHeaders::Get() may throw NS_ERROR_TYPE_ERR with an associated message.
The semantics of ErrorResult dictate that the message needs to be consumed by
the time that the object gets destroyed, so we need to clear it before
returning in these two places.
The test timeouts here are some form of bug 1141256, which causes the service
worker spawned in the parallel mode of the tests to never start up. It turns
out that avoiding sending this huge message to the mochitest logger avoids the
issue on the infrastructure, so let's re-enable these tests. Bug 1141256 still
needs to be investigated.
This patch was generated by a script. Here's the source of the script for
future reference:
find . \( -iname "*.cpp" -o -iname "*.h" \) | \
xargs -n 1 sed -i "s/nsRefPtr<nsIRunnable>/nsCOMPtr<nsIRunnable>/g"
Before this patch, we would only set these pragmas as part of CreateSchema
which runs in SetupAction. This meant that the connection used to perform
other DBActions would not have had these pragmas applied. As a result,
sqlite would not honor foreign keys on such connections, so the cascade
delete rules responsible for deleting rows from request_headers and
response_headers would not get executed when DBSchema::CachePut deleted the
old entry before adding a new one.
The test in the patch demonstrates how this could result in an observable
breakage. Before this patch, the response headers stored in the cache for
the overwritten entry would reflect both `Mirrored: `foo' and `Mirrored: bar'
headers, which means that attempting to get this header on the cached
response would return the first entry, `foo'.
These tests used .catch() incorrectly, in a way that did not actually
guarantee that the promise is rejected, so in 3 cases the promise
resolved to known failure values (undefined or an empty array) and
this was not being caught as a test failure.
This patch fixes those three places, and also rewrites the .catch()
usage in another case to guarantee that the promise is indeed rejected.
Here are the changes needed to achieve this:
* We tag each message posted to the framework with a context argument.
context can be one of "Window", "Worker" or "ServiceWorker". In the
places where we handle messages, we only handle the ones corresponding
to the context that we expect.
* We use Promise.all in order to interleave the execution of the tests.
This has the nice property of actually getting the tests run
simultaneously on multi-core machines.
* For ease of debugging test failures, we print the context from which
each test message is coming from.
* In order for the tests that are run in parallel to not step on each
other's toes, we introduce a global `context' variable that the test
script can use to create names that do not clash with concurrent
test runs. For example, instead of `caches.open("foo")', one must now
use: `caches.open("foo" + context)'.
* The existing tests are modified based on the above.
* When running the tests in parallel, the service worker may end up
controlling both frame.html and message_receiver.html. The hunk at
the end of worker_wrapper.js is intended to ensure that we will
always be communicating with message_receiver.html.
* An order argument has been added to runTests which can be set to
"sequential" in order to run the tests in different contexts in
parallel. If the argument is omitted, the default is "parallel".
