I’m trying to paginate Issues’ Comments accordingly to their docs that relies on the Link Header.
I perform the Request using a (Babel) Class’ method, a wrapper routine for the Fetch API, like this:
class MyClass {
async load( url, method = 'GET', args = {} ) {
const options = {
method: method.trim().toUpperCase(),
redirect: 'follow'
};
try {
const process = await fetch( url, Object.assign( options, args ) );
if( ! process.ok ) {
throw new Error( process.statusText );
}
return process.clone().json().catch( () => process.text() )
} catch( error ) {
return Promise.reject( error );
}
}
}
(new MyClass).load( 'https://api.github.com/repos/OWNER/REPOSITORY/issues/ISSUE/comments?page=1&per_page=15' );
I’ve suppressed a small bit of the code because, as you can see, I’m not returning the Fetch API Response Promise, only the resolved data, but I’ve tested it returning the thenable Promise itself and the results were the same.
For the sake of simplification, some simple debugging right after the process.ok
yields me:
Response Object (console.log( process )
)
{ type: "cors", url: "https://api.github.com/repos/OWNER/REPOSITORY/issues/ISSUE/comments?page=1&per_page=15", redirected: false, status: 200, ok: true, statusText: "OK", headers: Headers, body: ReadableStream, bodyUsed: false }
The Headers (iterating over process.headers.entries()
)
cache-control: private, max-age=60, s-maxage=60
content-type: application/json; charset=utf-8
etag: W/"5304658e191e2c59f9a26ca89366de5dcf3801d561b0307b0590282a672c4409"
x-accepted-oauth-scopes:
x-github-media-type: github.v3; param=html.squirrel-girl-preview; format=json
x-oauth-scopes: notifications, public_repo, user
x-ratelimit-limit: 5000
x-ratelimit-remaining: 4973
x-ratelimit-reset: 1638360867
x-ratelimit-resource: core
x-ratelimit-used: 27
x-ratelimit varies depending on the number of Requests performed within one hour
As you can see, no Link Header.
After some research, I’ve found this answer saying that over CORS only a few Headers are available and in its comments, I’ve learned that access-control-expose-headers
when configured in the server can expand this list.
Well, this is a screenshot of the Response Data:
Once again, x-ratelimit varies
As you can see, Link is present among access-control-expose-headers
, meaning that GitHub (apparently) did their part, and yet I can’t retrieve it.
With the case exposed so, how could I:
- Get this Link Header using the Fetch API (preferably)
- Or then build the pagination logic without it. Maybe using some math, perhaps?
What’s bugging me is that I’m 100% positive the very same code I have today was working ’til a few days ago when Firefox was updated. I’m sure of it because the whole implementation was working ’til 11/23, the date on which I’ve committed it to my repository.
In the meantime, Firefox was updated but I couldn’t find any information regarding a change in Fetch API, since I’ve read somewhere that using oldie XHtmlHttpRequest was still possible to get such headers.