-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pyodide_http patch_requests breaks COI expectations #40
Comments
Seems to be related to pyodide/pyodide#4068 Can you do:
If it prints 0.2.0 then the version is broken in firefox/safari due to the |
I am getting many |
Thanks for reporting this. What browser are you using? In the end it would be good to have a way to retrieve a list of “unsafe header” names, as those may differ per browser, and probably also over time. |
Tried Chrome, Edge, Firefox, same behavior. The HTML generated by Panel v1.4.4 loads Pyodide v0.25.0 (and specifies |
This was erroneously opened in here pyodide/pyodide#4191
🐛 Bug
While testing/demoing one of our apps in PSDC we noticed that while Chrome/ium was managing to load a 3rd party spreadsheet both Firefox and Safari were completely broken at the headers and permissions headers.
We use code from a worker which requires SharedArrayBuffer and while we managed to enable it, all requests were blocked by the browsers.
To Reproduce
The error in Safari is about headers messed up
ending up in pyodide as
A network error occurred.
Expected behavior
If we change the code to use XHR out of the box everything works without issues and no network warning is ever shown:
I suspect the error is somewhere in here: https://github.com/koenvo/pyodide-http/blob/main/pyodide_http/_core.py#L75
There are a lot of headers manipulation but in some cases browsers really don't like user-land code messing up with security related server defined headers so that override mime type, as example, can be considered insecure as well as anything else that would not otherwise be part already of the predefined headers.
I hence suggest to allow something like
patch_requests(ignore_headers=True)
so that nothing is changed but I am also not sure why non worker env should change anything at mime type expectations ... although I think that in our case that value isTrue
.Environment
The text was updated successfully, but these errors were encountered: