**Use case**
ClickHouse cannot accept connections from web browser-based query tools that implement [CORS protocol preflight requests](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request).  The reason is preflight checks use an OPTIONS request, which ClickHouse does not implement in the HTTP interface. 

The problem occurs in tools like Grafana and [ObservableHQ](https://observablehq.com), whenever (a) ClickHouse is on a different server from the web page source and (b) the call to ClickHouse is processed directly in the browser. This use case occurs commonly when integrating ClickHouse cloud implementations with SaaS-based BI tools. In each case the browser will do the following: 

1. Send an OPTIONS request to check if ClickHouse allows cross-site requests.  The browser expects to see an Access-Control-Allow-Origin header that whitelists the original site and a 200 status code.  
2. Once the OPTIONS request returns successfully, send the actual request. 

When Grafana tries to do this it fails with the following message in the browser console. ObservableHQ fails similarly. 

```
Access to fetch at 'https://github.demo.trial.altinity.cloud:8443/?add_http_cors_header=1' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
```
In the case of Grafana you can work-around CORS problems by running the ClickHouse queries on the Grafana server (set Access to 'Server' in the Datasource definition).  For ObservableHQ this is a blocking bug.  

There is another problem in that the current add_http_cors_header=1 option used to allow ClickHouse to return a Access-Control-Allow-Origin header makes client URLs more cumbersome. There's also a security issue in that CORS should be enabled by the server, not triggered by the client. Malicious sites can undo CORS protection by changing the URL. 

**Describe the solution you'd like**
ClickHouse should implement [server-side CORS support](https://enable-cors.org/server.html) fully, which includes the following: 

1. Implement OPTIONS requests for CORS preflight checks.  The expected behavior is shown in the referenced page above and illustrated in the attached Python3 script showing a typical OPTIONS request for pre-flight checks. Note that you can run a preflight request without authenticating. 
2. Make CORS support a server-side setting.  It would make sense to enable cors using a regex with '*' to designate accept all sites.  CORS should be off by default. 
3. Deprecate the add_http_cors_header=1 URL option as soon as possible. 

**Describe alternatives you've considered**
An alternative option is to enable CORS using a proxy, but this seems cumbersome and hard for developers.  If ClickHouse supports HTTP it should do it completely, including CORS. 

**Additional context**
As noted above this is a much more prominent problem with ClickHouse cloud platforms. 
: HTTPHandler(server_, "DynamicQueryHandler"), param_name(param_name_)
{
}
bool DynamicQueryHandler::customizeQueryParam(ContextMutablePtr context, const std::string & key, const std::string & value)
{
    if (key == param_name)
        return true;    
    if (startsWith(key, "param_"))
    {
        
        const String parameter_name = key.substr(strlen("param_"));
        if (!context->getQueryParameters().contains(parameter_name))
            context->setQueryParameter(parameter_name, value);
        return true;
    }
    return false;
}
std::string DynamicQueryHandler::getQuery(HTTPServerRequest & request, HTMLForm & params, ContextMutablePtr context)