Add support for headers in the server configuration

[navasvarela]

Small change to add support to configure server response headers.

The justification is that some client side libraries might require specific response headers in order to work. Currently it is not possible to modify the headers sent by Express.

[sgravrock]

Can you show me a concrete example of a problem that this solves? At a glance, it seems like it would only be useful if:

• Code under test legitimately needs to make requests to jasmine-browser-runner
• That code needs a particular header set
• Every response needs to provide the same exact header(s)

But maybe I'm missing something.

[navasvarela]

An example that I can think of is testing code that requires a particular set of HTTP headers set for the client side javascript to enable some browser features that are disabled by default.

For instance, some WASM modules require use of SharedArrayBuffer, which is disabled in most browsers due to security considerations. In order to enable ShardArrayBuffer some HTTP headers need to be set.

[sgravrock]

If I understand correctly, SharedArrayBuffer requires Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers to be set in the HTML document response. Setting it on every response might work, but it's unnecessarily heavy-handed. What if we later found ourselves needing to support a case that required setting headers only on specific responses? For example, if there was a need to provide a Content-Type header, that would need to be scoped to specific responses to avoid breaking JS and CSS. Having a headers configuration property that applies to all URLs would make adding that feature more difficult, and the result would likely be harder for users to understand. Additionally, some users are likely to expect that they can configure whatever headers they want without breaking jasmine-browser-runner.

I appreciate the PR, but I think this design falls between two stools: it's too specific for something that's designed around hypothetical future use cases, while also not being specific enough for the use case we've identified.

I'd be more comfortable with any of these options:

• Specific configuration to enable crossOriginIsolated
• Generic support for user-provided middleware, as discussed in Http proxy support #13
• Waiting until somebody shows up with a concrete problem that requires customizing headers, and then solving that