INTRODUCTION
During an update in my Win32 CEF application from chromium-73.0.3683.75 to chromium-92.0.4515.131, I have observed an unexpected behaviour CORS preflight triggered by XmlHTTPRequest.
The difference is in Access-Control-Request-Headers.
chromium-73.0.3683.7
- Code: Select all
OPTIONS /service.cgi HTTP/1.1
Host: 192.168.1.217
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: null
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) ...
Access-Control-Request-Headers: content-type
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: it_IT
chromium-92.0.4515.131
- Code: Select all
OPTIONS /service.cgi HTTP/1.1
Host: 192.168.1.217
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: null
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) ...
Access-Control-Request-Headers: accept-language,content-type
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: it_IT
With the new CEF I have error on response on some not upgradable embedded web-server:
- Code: Select all
Access to XMLHttpRequest at 'http://192.168.1.217/service.cgi' from origin 'null' has been blocked by CORS policy: Request header field accept-language is not allowed by Access-Control-Allow-Headers in preflight response.
The error is fired because this web server does not response with "accept-language" in "Access-Control-Allow-Headers".
I observed that Google Chrome (ver 92) doens not put "accept-language" in preflight request.
2 ATTEMPTS TO SOLVE MY PROBLEM
First attempt was to implement an empty CefResourceRequestHandler trying to intercept request.
I notice that, simply returning an empty CefResourceRequestHandler in CefRefPtr<CefResourceRequestHandler> MyCefHandler::GetResourceRequestHandler() caused a different behaviour in preflight request: "accept-language" disappeared from "Access-Control-Allow-Headers".
Debugging CEF code, I watched execution of this particular piece of code in resource_request_handler_wrapper.cc
- Code: Select all
// The request will be handled by the NetworkService. Remove the
// "Accept-Language" header here so that it can be re-added in
// URLRequestHttpJob::AddExtraHeaders with correct ordering applied.
request->headers.RemoveHeader(net::HttpRequestHeaders::kAcceptLanguage);
Second attempt: I focused on CefSettings.accept_language_list, without any CefResourceRequestHandler.
I tried to keep accept_language_list empty and I observed that preflight request, again, is built without "accept-language" in "Access-Control-Allow-Headers".
I also tried to set accept_language_list with the same default value "en_US", but it cause preflight response error.
So, I deduced that assignment, use and controls on accept_language_list is radically changed, with some butterfly effects on preflight.
Note that, before this attempt, I used to fill accept_language_list with languages supported by OS and I would like to keep this behaviour (the same as Google Chrome),
FINAL CONSIDERATIONS AND QUESTIONS
Web server that I need to support, cannot be upgraded, so I need CEF preflight headers behave same as Google Chrome.
I have found two workarounds to solve my problem (preflight without "accept-language"), but they both seems not reliable to me, specially for the future.
Am I right?
Are there better alternatives to achieve my goal?
Thank you in advance.