[RFC 7231 OPTIONS](https://tools.ietf.org/html/rfc7231#section-4.3.7)
> A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow)
> A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.
[RFC 7231 405 Method Not Allowed](https://tools.ietf.org/html/rfc7231#section-6.5.5)
> The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods
Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
A tweak to the change introduced in c4b5707747 to fix#9952.
This will allow clients that don't support the * value in `Access-Control-Allow-Headers`,
but do specify the `Access-Control-Request-Headers` (such as electron 2.0.2) to use dynamic import.
Another way to fix#9888: properly handle OPTIONS requests by returning
permissive CORS headers, so that the dynamic import() server can respond
to requests from any origin.
Just as the URLs of static JS resources depend on request.browser, so too
must dynamic modules be loaded from the correct build directory based on
the user agent string of the __meteor__/dynamic-import/fetch HTTP request.
Letting dynamic-import depend on packages that depend on ecmascript means
ecmascript and its dependencies can't depend on dynamic-import. This
commit gives us back that flexibility.
Each time the server starts, the dynamic-import/server.js module creates a
secret key for accessing dynamic server modules, then exposes that key to
the server-side dynamic-import/client.js module, and no one else.
If client.setSecretKey has been called, that key will be included as a
query parameter in each /__dynamicImport POST request. If it matches the
actual secret key, access is granted to the corresponding dynamic modules;
otherwise, only web.browser dynamic modules are made available.
Ever since Meteor 1.5 first shipped, dynamic modules have been fetched
over a WebSocket, which is appealing because sockets have very little
latency and metadata overhead per round-trip.
However, using a WebSocket requires first establishing a socket connection
to the server, which takes time and may require a WebSocket polyfill.
An even more subtle problem is that we cannot use dynamic imports in any
of the code that implements the ddp-client package, as long as the
dynamic-import package depends on ddp-client.
By switching from WebSockets to HTTP POST requests, this commit radically
reduces the dependencies of the dynamic-import package, while preserving
(or even exceeding) the benefits of socket-based dynamic module fetching:
1. The client makes a single HTTP POST request for the exact set of
dynamic modules that it needs, which is much cheaper/faster than making
several/many HTTP requests in parallel, with or without HTTP/2.
2. Because the client uses a permanent cache (IndexedDB) to avoid
requesting any modules it has ever previously received, the lack of
HTTP caching for POST requests is not a problem.
3. Because the HTTP response contains all the requested dynamic modules in
a single JSON payload, gzip compression works across modules, which
produces a smaller total response size than if each individual module
was compressed by itself.
4. Although HTTP requests have more latency than WebSocket messages, the
ability to make HTTP requests begins much sooner than a WebSocket
connection can be established, which more than makes up for the latency
disadvantage.
5. HTTP requests are a little easier to inspect and debug in the dev tools
than WebSocket frames.
6. The new /__dynamicImport HTTP endpoint is a raw Connect/Express-style
endpoint, so it bypasses the Meteor method-calling system altogether,
which eliminates some additional overhead.
7. Fetching dynamic modules no longer competes with other WebSocket
traffic such as DDP and Livedata.
8. Although the implementation of the /__dynamicImport endpoint is a bit
too complicated to allow serving dynamic modules from a CDN, that
remains a possibility for future experimentation. In other words, how
modules are fetched is still just an implementation detail of the
`meteorInstall.fetch` callback.
9. As with the WebSocket implementation, the module server is totally
stateless, so it should be easy to scale up if necessary.
I wish I had appreciated the advantages of an HTTP-based implementation
sooner, but I think the transition will be pretty seamless, since the new
implementation is completely backwards compatible with the old.
This prevents __dynamicImport from blocking other method calls made by the
application, but introduces the possibility that __dynamicImport method
results could be delivered out of order, which is now handled in the
fetchMissing function.
