rpc
rpc copied to clipboard
ApiRequester.simpleRequest() sets unsafe headers causing Chrome to report "Refused to set unsafe header"
I'm using Rpc package and it uses http.BrowserClient to send API requests to the server.
However on each POST request, Chrome reports two errors saying:
Refused to set unsafe header "user-agent"
Refused to set unsafe header "content-length"
These two headers are not allowed to be set in a browser as per http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method.
It would be great if Rpc requests from the client skipped setting the headers that are not allowed by the browsers.
As Tristan mentioned you can work around this for the moment by wrapping the client and have the wrapper remove the two headers before sending the request.
Didn't mean to close the issue.
I am trying to work around this issue. I have a Client
which extends the http.BrowserClient
and I am trying to unset the headers:
Future send(var request) {
request.headers['authorization'] = 'Bearer ${this.key}';
request.headers['Cookie'] = null;
request.headers['user-agent'] = null;
request.headers['content-length'] = null;
return super.send(request);
}
The Authorization
header gets set correctly but the other three are not overwritten. I am not sure what I'm doing wrong?
@Sgoettschkes The issue might be that the entry is still in the map, since setting the value to null
doesn't remove the entry from the map:
void main() {
print({'key' : 'value'});
print({'key' : 'value'}..['key'] = null);
print({'key' : 'value'}..remove('key'));
}
will print
{key: value}
{key: null}
{}
@mkustermann And you save me again :) Using remove
works, thanks!
I am using the Stubs client generated with command pub run rpc:generate client -i lib/server/api.dart -o lib/client
and the error commented in this issue is occuring:
Is there a workaround?
The workaround is is basically described above: Wrap the underyling browser-based http client and remove the 2 headers before sending it further.
For background knowledge: The generated api client libraries try to supply as much information to the underlying http.Client
as they can, which includes the user-agent
and the content-length
headers (which are very useful for some http clients). Though in the browser case the http client is not allowed to override these headers, because the browser sets them itself.
@jakobr-google I think the easiest solution would be to allow the generated client libs to accept a boolean whether to set these headers, or have a wrapping-http-client for people to use. Would you be interested in looking into this?