Improve Cross-Origin Resource Sharing (CORS) HST support through preflight (OPTIONS) requests

Currently, the HST does only properly support a preflight (OPTIONS) requests for requests that are handled by a valve that uses CXF (jaxrs). For the default aggregation pipeline the HST returns a 405 (not supported), for other pipelines the HST does not handle the OPTIONS requests correct: It can set some headers, but also renders the response

The HST can be setup to response with the correct response headers when it is invoked from a different origin, however, it is not very handy at the moment: You need to set hst:responseheaders property, which isn't flexible enough, certainly not for the PMA (page model API). For the PMA support in combination with Relevance, we need to be able to

1) Support requesting the PMA with a custom header (_visitor)
2) Support to be able to access cookies from the domain on which the HST is invoked (Access-Control-Allow-Credentials: true)

For (2) however, when the HST responds with Access-Control-Allow-Credentials: true, the HST should not respond with

Access-Control-Allow-Origin: *

because in case of Access-Control-Allow-Credentials: true, an explicit Origin is required!

In HST response headers, you can configure

Access-Control-Allow-Origin: *

however, when serving the response we should replace the * with the domain from the current request! Then we still cannot support everything we want since we also want to support for example that we can specify the the only origins that are allowed are for example

1. http://www.example.com
2. http://www.example.org
   You can however not specify

   Access-Control-Allow-Origin: http://www.example.com, http://www.example.org
   

   since the Access-Control-Allow-Origin return value must be either * or a single host!

Hence we have to introduce in the HST something like

hst:allowedorigins

specifying the CORS origin whitelists.

So suggested changes to the HST:

1. For PMA, by default we add Access-Control-Allow-Credentials: true
2. For hst:responseheaders containing Access-Control-Allow-Origin: *, we replace '*' in the response with the explicit request origin
3. If the HST does not contain Access-Control-Allow-Origin: * header but it does contain hst:allowedorigins multi-valued property, we return Access-Control-Allow-Origin: request-domain-host if the domain is whitelisted
4. The HST will need to support a service through which downstream modules/projects can tell which headers (Access-Control-Allow-Headers) are allowed
5. The HST will by default for all NON-CXF (jaxrs) pipelines by default support "HEAD", "GET", "POST" as allowed methods
6. The HST will include by default ACCESS_CONTROL_MAX_AGE for the preflight OPTIONS requests. We'll set it to 1 day by default for now, see [2]
7. The HST will include a header Vary: Origin which is very important to avoid cached responses for preflight requests from different origins

Extra thing to note:

On hst:responseheaders properties, we cannot use

Access-Control-Allow-Headers: *

since in general we also need

Access-Control-Allow-Credentials: true

and with Access-Control-Allow-Credentials: true, then the Access-Control-Allow-Headers: * is treated differently, see [4]

[1] https://dev.to/miguelmota/understanding-cross-origin-resource-sharing-cors-2i3e
[2]

Firefox doesn't allow items to be cached longer than 24 hours while Chrome, Opera, and Safari cache items for a maximum of 5 minutes. If the Access-Control-Max-Age isn't specified then Firefox doesn't cache the preflight while Chrome, Opera, and Safari cache the preflight for 5 seconds.
Maximize the Access-Control-Max-Age header for a better mobile experience by reducing number of network requests.

To prevent proxy servers from caching responses from one client and sending them to a different client, use the Vary: Origin response header to indicate that the Access-Control-Allow-Origin will differ and should not be cached
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary

• (wildcard)
  The value "" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "" without special semantics. Note that the Authorization header can't be wildcarded and always needs to be listed explicitly.
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers