Content type not set correctly due to no-cors

[andyshinn]

Hi. Cool idea.

I was trying to get this working with Home Assistant incoming webhook (https://www.home-assistant.io/docs/automation/trigger/#webhook-trigger) and noticed that the webhook being sent is not actually of Content-Type: application/json (event though it is set that way): https://github.com/jpoehnelt/chrome-meet-webhook-extension/blob/master/src/webhook.ts#L37-L39. My POST requests are sent as text/html and Home Assistant doesn't use the body so my data is empty.

Upon closer debugging I found the fetch() API documentation calling out the headers limitation at https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch:

Note that mode: "no-cors" only allows a limited set of headers in the request:

Accept
Accept-Language
Content-Language
Content-Type with a value of application/x-www-form-urlencoded, multipart/form-data, or text/plain

It looks like POSTing JSON is at odds with the no-cors option. Are you actually using this in Chrome and successfully POSTing as JSON?

[jpoehnelt]

I have only been using the template pattern in the url and ignoring the body. Do you know if the server is open to CORS? If it is we could enable the preflight options check.

[andyshinn]

I do not know. But i'll play with it. I actually hacked it to send the body as URL encoded (which works).

[jpoehnelt]

Should probably default to that instead. Opened #69 .

[github-actions]

🎉 This issue has been resolved in version 1.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀