Support for OPTIONS request for CORS reasons

[kmiller15211]

Support for OPTIONS request for CORS reasons

[mattgodbolt]

Right! That seems to be what's happening here. We'll need to support OPTIONS to get this to work. I'll rename this issue accoridngly.

[mattgodbolt]

Hi there!

When you do the writer->header(...) stuff, does the header actually make it into the header of the reply? Or does it appear in the body?

You can test with curl for example:

curl -D- http://localhost:1234/path/to/your/thing
``` (assuming GET here, but there are arguments to make it PUT etc)

the `-D-` says "output the headers to stdout`, so you should see them, followed by a blank line, followed by the body.

We can definitely add CORS support, but it _should_ be "just" adding the headers. My guess is that isn't working here!

[kmiller15211]

Thanks for the response! Here is my command, and the response. Seems like it's correctly returning the header, as expected:

~ # curl -D- --request GET '192.168.1.203:80/config/param?category=holter&paramName=framSizeBytes'
HTTP/1.1 200 OK
Server: 1.3.2
Date: Thu, 22 Apr 2021 18:50:25 GMT
Access-Control-Allow-Origin: *
Content-type:
Access-Control-Allow-Origin: *

{"value":1048576}

A few things to note: Our endpoint is dangled off of the main page handler - wouldn't our endpoint returning the CORS header as shown above come AFTER the preflight failure, meaning it would never have a chance to take effect? That matches what we're seeing in practice; When any of our Seasocks REST endpoints are hit, we typically see a journal that we're servicing endpoint "X/Y/Z". We're not seeing that here, so it seems like it's dead ended before it even has a chance to return that header.

[mattgodbolt]

It actually looks like it's in there twice....

and yes, grepping the code we already put Access-Control-Allow-Origin: * in our messages! (Connection.cpp)...!

So, as best I can tell the CORS is working...but

my guess is the "preflight" it's talking about is doing a HEAD or something? can you wireshark capture and see if that's the case (I'm clutching at straws here; we don't support HEAD right now but could...I think. It's bee a while...)

[kmiller15211]

OK, here's a Wireshark trace from what we're seeing. In this case, we have a PC running Chrome attempting to access the embedded Linux device running seasocks with page handlers - with a GET request of 'http://192.168.137.138/system/serial-number. The Chrome application returns the following error information:

Access to fetch at 'http://192.168.137.138/system/serial-number' from origin 'http://dpcpo-farga-132dtn1y09cpq-1698599008.us-east-1.elb.amazonaws.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

cors-request-packet-trace-2021-04-26.txt

[mattgodbolt]

Hi! Can you attach the packet capture itself instead of the text? It's much easier to debug in wireshark than in a text editor :) thanks!

[mattgodbolt]

ah!
I was able to read enough:

Hypertext Transfer Protocol
    OPTIONS /system/serial-number HTTP/1.1\r\n
    Host: 192.168.137.138\r\n

is what was sent, which we don't support I think? Hard to tell

[kmiller15211]

Sorry, here's the full trace (I hope). Unfortunately, getting this secondhand, as I'm having device/networking issues.

The request should have been a GET of this URL: 'http://192.168.137.138/system/serial-number'.

cors-request-packet-trace-wireshark.zip

[kmiller15211]

We believe that the OPTIONS call is the pre flight check to ensure that the web domain is allowed to call that API. (Sorry, I'm not a HTTP expert; We believe this is part of the standard, so I'll apologize upfront if I have this wrong).

[mattgodbolt]

Relevant docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#functional_overview

[mattgodbolt]

and https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS#preflighted_requests_in_cors