Issue description
Suppose you have blackd running locally. When sending requests to blackd that originate from another site (i.e., anywhere that's not localhost), you cannot use custom headers, despite the fact that blackd is configured to accept them (e.g., X-Line-Length or X-Python-Variant -- see the docs).
Explanation
This is because blackd, by default, does not allow cross-origin requests. (This itself is a property of aiohttp -- see the docs.) When sending a cross-origin request to blackd, you'll get a CORS error. If you try to get around this by sending a no-cors request, you cannot send custom headers. See this StackOverflow answer for why this is the case; but this essentially means that if a request comes from an origin different from where blackd is running, the custom headers will not be accepted.
Example -- how it should always work
Run blackd locally in one terminal. From another terminal, these will produce the following output:
$ curl http://127.0.0.1:45484 -X POST -d 'print("something very long", x, y = 122, z= 8)'
print("something very long", x, y=122, z=8)
$ curl http://127.0.0.1:45484 -X POST -d 'print("something very long", x, y = 122, z= 8)' -H "X-Line-Length: 40"
print(
"something very long", x, y=122, z=8
)
Both of these are expected behavior. You can verify that the same happens when sending requests in Postman, if you'd like.
Example -- how it doesn't work from other origins
Run blackd locally in a terminal. Go into the console on any website on the newest version of Chrome (or probably any other modern browser, but I didn't try). We can use the fetch API (see this StackOverflow answer for more info) to send requests.
Type this in the console:
fetch("http://127.0.0.1:45484", { method : "POST", body: 'print("something very long", x, y = 122, z= 8)' })
You'll get a CORS error:
Access to fetch at 'http://127.0.0.1:45484/' from origin <website you're on> has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
We can set the mode to no-cors to suppress the error:
fetch("http://127.0.0.1:45484", { method : "POST", body: 'print("something very long", x, y = 122, z= 8)', mode: 'no-cors' })
and it works fine. Go into the Network tab to verify that you got a 200 response.
But what if we want to set the line length? Because of the reasons described in the StackOverflow answer above (thatno-cors mode doesn't allow custom headers), we cannot send a request with this. In other words, the following will not work:
h = new Headers({ 'Content-Type': 'text/plain', "X-Line-Length" : 40 })
fetch("http://127.0.0.1:45484", { method : "POST", body: 'print("something very long", x, y = 122, z= 8)', mode: `no-cors`, headers: h })
You can look in the Network tab at the request that got sent to verify that the custom headers didn't go through. We get the same response as before.
Resolution
This can be resolved by adding CORS support to blackd. This is simple to do: in the aiohttp family is aiohttp-cors, which lets you enable CORS on the web applications.
It looks like this would require adding a dependency of aiohttp-cors (which should be fine, since blackd already is packaged separately and requires aiohttp) and changing some lines in make_app. I have made a local change that allows this, and am happy to make a pull request for it to be reviewed, but I wanted to open an issue to discuss it first.
Other information
OS: MacOS 10.13.6, High Sierra
black (and blackd) version: 18.9b0
Python version: 3.6.7
Does this happen on master: yes
Issue description
Suppose you have blackd running locally. When sending requests to blackd that originate from another site (i.e., anywhere that's not localhost), you cannot use custom headers, despite the fact that blackd is configured to accept them (e.g.,
X-Line-LengthorX-Python-Variant-- see the docs).Explanation
This is because blackd, by default, does not allow cross-origin requests. (This itself is a property of aiohttp -- see the docs.) When sending a cross-origin request to blackd, you'll get a CORS error. If you try to get around this by sending a
no-corsrequest, you cannot send custom headers. See this StackOverflow answer for why this is the case; but this essentially means that if a request comes from an origin different from where blackd is running, the custom headers will not be accepted.Example -- how it should always work
Run blackd locally in one terminal. From another terminal, these will produce the following output:
Both of these are expected behavior. You can verify that the same happens when sending requests in Postman, if you'd like.
Example -- how it doesn't work from other origins
Run blackd locally in a terminal. Go into the console on any website on the newest version of Chrome (or probably any other modern browser, but I didn't try). We can use the fetch API (see this StackOverflow answer for more info) to send requests.
Type this in the console:
You'll get a CORS error:
We can set the mode to
no-corsto suppress the error:and it works fine. Go into the Network tab to verify that you got a 200 response.
But what if we want to set the line length? Because of the reasons described in the StackOverflow answer above (that
no-corsmode doesn't allow custom headers), we cannot send a request with this. In other words, the following will not work:You can look in the Network tab at the request that got sent to verify that the custom headers didn't go through. We get the same response as before.
Resolution
This can be resolved by adding CORS support to blackd. This is simple to do: in the aiohttp family is aiohttp-cors, which lets you enable CORS on the web applications.
It looks like this would require adding a dependency of aiohttp-cors (which should be fine, since blackd already is packaged separately and requires aiohttp) and changing some lines in
make_app. I have made a local change that allows this, and am happy to make a pull request for it to be reviewed, but I wanted to open an issue to discuss it first.Other information
OS: MacOS 10.13.6, High Sierra
black (and blackd) version: 18.9b0
Python version: 3.6.7
Does this happen on master: yes