[BUG] Browser unable to parse response headers from ExtensionRestResponse

[mzainab24]

What is the bug?

While using the extension, I connected my python extension with a React frontend to send requests through a browser. My frontend and backend were both running on localhost but on different ports. So the browser gave me a CORS error “no ‘access-control-allow-origin’ header is present on the requested resource” error.
Upon trying to solve this error and get the response on the browser, I tried adding the required response headers that are suggested to solve the CORS error.
My response header object looks as the following and my response object is of the type ExtensionRestResponse.

        #headers: dict[str, list[str]] = dict()
        response_headers = {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Headers": "Content-Type,Authorization",
        "Access-Control-Allow-Methods": "GET,PUT,POST,DELETE,OPTIONS",
        } 

However, the browser does not parse the headers correctly, since the type of headers in the class ExtensionRestResponse is "headers: dict[str, list[str]] = dict(),"

So on the browser, the headers are always parsed as a list of strings.

And hence the browser cannot find the appropriate response headers to resolve the CORS issue.
I added the Chrome extension "Allow CORS: Access-Control-Allow-Origin" to make the requests temporarily working.

How can one reproduce the bug?

Add the above response headers in a sample request-response and the list could be seen from the console too.

What is the expected behavior?

The request should give the CORS error “no ‘access-control-allow-origin’ header is present on the requested resource” on the browser.

What is your host/environment?

Backend running on:
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Architecture: x86-64
Frontend accessed from:
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
Browser: Google Chrome Version 126.0.6478.114 (Official Build) (64-bit)

Do you have any screenshots?

If applicable, add screenshots to help explain your problem.

Do you have any additional context?

Add any other context about the problem.

[dbwiddis]

@mzainab24 this is a good point to note that I was new to Python when I wrote this code and clearly made an error here. I'll look into it over this long weekend. :|

[dblock]

@mzainab24 We'd love your help fixing these bugs, too! Don't let @dbwiddis pick it all up :)

[mzainab24]

@dblock and @dbwiddis sure, thanks. I will try to fix it too and post the solution. :)
I also had similar problem with requests. My requests that took longer would always end up being timed out by the extension without receiving a response since the process to provide to response would still be running at the back but the extension would return a timeout. And I couldn't add timeout headers in the request.

[dbwiddis]

My response header object looks as the following and my response object is of the type ExtensionRestResponse.

        #headers: dict[str, list[str]] = dict()
        response_headers = {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Headers": "Content-Type,Authorization",
        "Access-Control-Allow-Methods": "GET,PUT,POST,DELETE,OPTIONS",
        } 

Have you tried this?

        response_headers = {
        "Access-Control-Allow-Origin": ["*"],
        "Access-Control-Allow-Headers": ["Content-Type", "Authorization"],
        "Access-Control-Allow-Methods": ["GET", "PUT", "POST", "DELETE", "OPTIONS"],
        } 

Or, alternately

        #headers: dict[str, list[str]] = dict()
        response_headers = {
        "Access-Control-Allow-Origin": "*".split(','),
        "Access-Control-Allow-Headers": "Content-Type,Authorization".split(','),
        "Access-Control-Allow-Methods": "GET,PUT,POST,DELETE,OPTIONS".split(','),
        } 

[mzainab24]

@dbwiddis yes, the CORS error still holds.

[dbwiddis]

@mzainab24 I need a bit more clarity on where you are interacting with the extension via your browser.

The type dict[str, list[str]] is meant to exactly match the OpenSearch RestResponse type for headers:

private Map<String, List<String>> customHeaders;

Extensions normally don't reply to HttpClients directly, those clients hit OpenSearch, and the RestRequest is serialized to the extension, and an appropriate RestResponse is serialized back. The transport layer serialization is expecting exactly this format; iterating over a list to call addHeader() on the responses, and it's sent in an OutboundMessageResponse by the ExtensionRestRequestHandler. It's later used by OpenSearch in the RestChannel where it expects a Map<String, List<String>> of custom headers and adds its own headers to it.

Extensions in general (and thus this Python implementation) don't maintain their own incoming Rest Handlers; all their incoming communication is over transport.

So I am not sure there is any bug, and if you're trying to use a Python Rest Server to handle things, you need to do similar things as the OpenSearch RestChannel to parse headers to/from this data type.

[dblock]

@mzainab24 The explanation above boils down to the fact that your browser should be talking to the OpenSearch server instance on its port, not to anything the extension exposes.