empty headers in in afterware link
See original GitHub issueIntended outcome:
I’m setting a custom header on the response I’m supposed being able to access in the afterware link
Actual outcome:
The headers object is empty
How to reproduce the issue:
Some context: I have a custom header in response visible in network tab but not in the response object.
I know that the custom header is stripped away by the browser as this is a CORS request so I put it into Access-Control-Expose-Headers.
Now the browser exposes the custom header just fine as you may see in the screenshot and I should be able to access it within the afterwareLink. Though that’s not the case.
The headers object is always empty though getContext yields forceFetch
and cache
fields
I’m using: CLIENT: “apollo”: “0.2.2”, “apollo-cache-inmemory”: “1.1.0”, “apollo-client”: “2.0.2”, “apollo-link”: “1.0.0”, “apollo-link-context”: “1.0.0”, “apollo-link-error”: “1.0.0”, “apollo-link-http”: “1.1.0”, “graphql”: “0.11.7”, “graphql-tag”: “2.5.0”, “vue”: “2.5.3”, “vue-apollo”: “3.0.0-alpha.2”,
SERVER: “apollo-server-express”: “1.2.0”, “body-parser”: “^1.17.1”, “cors”: “^2.8.3”, “express”: “^4.15.2”, “graphql-tools”: “^1.2.3”,
Afterware code:
const afterwareLink = new ApolloLink((operation, forward) => {
const { headers } = operation.getContext();
console.log(operation.getContext());
if (headers) {
const refreshToken = headers.get('x-refresh-token');
console.log('refreshToken', refreshToken);
}
return forward(operation);
}
Version
- apollo-client@2.0.2
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (3 by maintainers)
@Knaackee That’s ok I guess as it is the same thing I see in mine.
However
headers.get('x-refresh-token')
correctly retrieves the token and I can both console.log it and set it in the localStorage in the afterware code.Do you mean it is not working for you? I mean retrieving the header using
headers.get('x-refresh-token')
A complete example:
Wasted a couple of hours too 😃
Looks like if you
console.log
headers, it will appear as empty. Iterating over it doesn’t work either.Whereas getting the header by name:
context.response.headers.get('...')
magically works. Now only to find the Chrome engineer who is responsible for this behavior…