Coverage increased (+0.02%) to 37.331% when pulling 8ad022d on cors-configuration into f0457c8 on master.

Just tested it, if I didn't make an error, I don't see the CORS info in the response header:

Current master server response headers:

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2019 15:10:21 GMT
Content-Type: application/xml; charset=UTF-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Transfer-Encoding: chunked

PR server response headers (with CORS default config in grobid-service/config/config.yaml):

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2019 15:07:29 GMT
Content-Type: application/xml; charset=UTF-8
Transfer-Encoding: chunked

Just tested it, if I didn't make an error, I don't see the CORS info in the response header:

Current master server response headers:

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2019 15:10:21 GMT
Content-Type: application/xml; charset=UTF-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Transfer-Encoding: chunked

PR server response headers (with CORS default config in grobid-service/config/config.yaml):

HTTP/1.1 200 OK
Date: Sat, 28 Dec 2019 15:07:29 GMT
Content-Type: application/xml; charset=UTF-8
Transfer-Encoding: chunked

I tried it with ajax/jquery and it is ok ! , I ll do further tests, something weird..

I need to have a look at it again ...

Basically this implementation does not return headers if the Origin doesn't match the allowed origin or it's absent... it seems the proper way to do so, but it's not as I remember this thing...

ah my bad, I didn't put Origin: http://localhost in the requesting header indeed! I though corsAllowedOrigins: "*" would also match an absent Origin field.

Adding for instance Origin: http://localhost with the default server config works as expected - in the server response header, we have Access-Control-Allow-Origin: http://localhost Access-Control-Allow-Credentials: true.

I just added some minor corrections which were stuck in my local branch with 66de8d5