1

I did try to change the headers like follow

const httpOptions = {
  headers: new HttpHeaders({
    origin: 'https://custom.url.com',
    responseType: 'text',
  }),
}

console.log('here')
return new Promise((resolve, reject) => {
  this._httpClient
    .get(
      'https://any.url.com',
      httpOptions,
    )
    .subscribe((res) => {
      console.log(res)
   })
})

But I get an Refused to set unsafe header "origin" from the browser.

enter image description here

Does somebody did fix the error?

The reason I want to do this, is because I'm running angular in electron, and this do not send any origin...

Raphaël Balet
  • 6,334
  • 6
  • 41
  • 78

1 Answers1

1

This is normal behavior. Manually setting the origin header is forbidden by the browser. It is a Forbidden Header Name If no origin header is being added by your http client, it's because under some conditions, the origin header doesn't get added. I don't know enough to tell you which of these conditions your app is meeting, but you can read more about them on MDN.

Charles Desbiens
  • 879
  • 6
  • 14
  • I'm also an electron user, and there I'm able to change the origin and everything works like expected, could you explain me the reason why ? And why does angular then do not show that we shall not set the origin ? – Raphaël Balet Jul 08 '21 at 09:46
  • 1
    You can change the origin header in Electron because you can modify the user agent that is sending requests. Angular on the other hand isn't allowed to modify the user-agent. When Angular sends a request, it's sending it from your browser. For obvious reasons, websites aren't allowed to reprogram your browser's user agent. – Charles Desbiens Jul 08 '21 at 10:00
  • Thx a lot, it's more clearer now. Still do not understand why angular do not provide any type validation for this one. – Raphaël Balet Jul 08 '21 at 10:49
  • @Raphaël Balet Angular doesn't validate forbidden headers at run time because it doesn't need to. The browser takes care of that already. – Charles Desbiens Jul 08 '21 at 21:08
  • As for giving you warnings during development, that would have to be done by the TypeScript compiler. The TypeScript compiler isn't a system for validating values though; it's a system for validating the types that values will have. There is no concept of a "NOT" type that would allow for excluding a subset of possible values that otherwise have the intended type (in this case 'string'). – Charles Desbiens Jul 08 '21 at 21:17