Reading response headers with Fetch API

Question

I'm in a Google Chrome extension with permissions for "*://*/*" and I'm trying to make the switch from XMLHttpRequest to the Fetch API.

The extension stores user-input login data that used to be put directly into the XHR's open() call for HTTP Auth, but under Fetch can no longer be used directly as a parameter. For HTTP Basic Auth, circumventing this limitation is trivial, as you can manually set an Authorization header:

fetch(url, {
  headers: new Headers({ 'Authorization': 'Basic ' + btoa(login + ':' + pass) })
  } });

HTTP Digest Auth however requires more interactivity; you need to read the parameters that the server sends you with its 401 response to craft a valid authorization token. I've tried reading the WWW-Authenticate response header field with this snippet:

fetch(url).then(function(resp) {
  resp.headers.forEach(function(val, key) { console.log(key + ' -> ' + val); });
})

But all I get is this output:

content-type -> text/html; charset=iso-8859-1

Which by itself is correct, but that's still missing around 6 more fields according to Chrome's Developer Tools. If I use resp.headers.get("WWW-Authenticate") (or any of the other fields for that matter), I get only null.

Any chance of getting to those other fields using the Fetch API?

Answer 1

There is a restriction to access response headers when you are using Fetch API over CORS. Due to this restriction, you can access only following standard headers:

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

When you are writing code for Google Chrome extension, you are using CORS, hence you can't access all headers. If you control the server, you can return custom information in the response body instead of headers

More info on this restriction - https://developers.google.com/web/updates/2015/03/introduction-to-fetch#response_types

Answer 2

If it's NOT CORS:

Fetch does not show headers while debugging or if you console.log(response.headers).

You have to use following way to access headers.

fetch(url).then(resp=>{
    console.log(resp.headers.get('x-auth-token'));
})

// or
fetch(url).then(resp=>{
    console.log(...resp.headers);
})

Answer 3

The Problem:

You may think this is a Frontend Problem.
It is a backend problem.
The browser will not allow to expose the Authorization header, unless if the Backend told the browser to expose it explicitly.

How To Solve It:

This worked for me.
In the backend (The API), add this to the response header:

response.headers.add("Access-Control-Expose-Headers","Authorization")

Why?

Security.
To prevent XSS exploits.
This request is supposed to be from backend to backend.
And the backend will set up the httpOnly cookie to the frontend.
So the authorization header should not be accessible by any third party JS package on your website.
If you think that it safe is to make the header accessible by frontend, do it.
But I recommend HttpOnly Cookies set up by the server backend to your browser immediately.

Reference:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers

Answer 4

From MDN

You can also get all the headers by accessing the entries Iterator.

// Display the key/value pairs
for (var pair of res.headers.entries()) {
   console.log(pair[0]+ ': '+ pair[1]);
}

Also, keep in mind this part:

For security reasons, some headers can only be controlled by the user agent. These headers include the forbidden header names and forbidden response header names.

Answer 5

For backward compatibility with browsers that do not support ES2015 iterators (and probably also need fetch/Promise polyfills), the Headers.forEach function is the best option:

r.headers.forEach(function(value, name) {
    console.log(name + ": " + value);
});

Tested in IE11 with Bluebird as Promise polyfill and whatwg-fetch as fetch polyfill. Headers.entries(), Headers.keys() and Headers.values() does not work.

Answer 6

For us to fix this restriction issue, adding exposed header names is good enough.

access-control-expose-headers: headername1, headername2, ...

After setting this header, the client side script is able to read those headers (headername1, headername2, ...) from the response.

Answer 7

In response to a cross-origin request, add 'Access-Control-Expose-Headers': '*' to your response header, so that all headers are available to be read in your client side code. You can also indicate which headers you want to expose by specifying the header names instead of a wildcard.

Note that per MDN the '*' wildcard is treated as a literal if the URL you are accessing has "credentials".

Answer 8

If you're using .net in Program.cs file or Startup.cs depending on the .net version you have to do something like this:

builder.Services.AddCors(options =>
{
    options.AddPolicy(MyAllowSpecificOrigins,
    builder =>
    {
        builder
            .SetIsOriginAllowed(p => true)
            .WithOrigins("http://localhost:3000", "http://*:3000")
            .AllowCredentials()
            .WithExposedHeaders("X-Pagination") /*custom header*/
            .AllowAnyHeader()
            .AllowAnyMethod();
    });
});

}

Answer 9

I'll compile my solution that is all from above:

For get header use:

response.headers.get('ex-token')

In order to this to work, we must set on backend api exposeHeader('ex-token')`

With Java Spring became like this:

        configuration.addExposedHeader("ex-token");