Missing "Status" in response header

GitHub Ecosystem REST API
#1

According to the documentation on Resources in the REST API - GitHub Docs, this what a response should look like:

$ curl -I https://api.github.com/users/octocat/orgs

> HTTP/1.1 200 OK
> Server: nginx
> Date: Fri, 12 Oct 2012 23:33:14 GMT
> Content-Type: application/json; charset=utf-8
> Status: 200 OK
> ETag: "a00049ba79152d03380c34652f2cb612"
> X-GitHub-Media-Type: github.v3
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4987
> X-RateLimit-Reset: 1350085394
> Content-Length: 5
> Cache-Control: max-age=0, private, must-revalidate
> X-Content-Type-Options: nosniff

However, since last week, the status field seems to be missing:

$ curl -I https://api.github.com/users/octocat/orgs

HTTP/2 200
date: Tue, 09 Feb 2021 14:04:33 GMT
content-type: application/json; charset=utf-8
content-length: 5
server: GitHub.com
cache-control: public, max-age=60, s-maxage=60
vary: Accept, Accept-Encoding, Accept, X-Requested-With, Accept-Encoding
x-github-media-type: github.v3; format=json
access-control-expose-headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'
x-ratelimit-limit: 60
x-ratelimit-remaining: 59
x-ratelimit-reset: 1612883073
x-ratelimit-used: 1
accept-ranges: bytes
7 Likes
#2

I can see what you mean in the docs, but in those examples the Status header seems to be redundant, and just repeats the HTTP response status. Maybe use that instead?

#3

Thank you for your answer!

Sadly it’s not under my control.
An external library is using it, which has been crashing since Friday last week (5th of feb 2021)

#4

Ah, I see! I don’t know if the change was intentional from Github, so I can’t say if the header might be added back. I think reporting a bug against that external library would be good either way.

#5

Hi @thulin82 :wave: This is a change from our (GitHub’s) side where the status header is no longer being returned as of very recently. The status header was previously included by the rack server we use and the newer version has removed it. The infrastructure team confirmed that we won’t be able to roll this back and restore the header unfortunately.

The workaround is to use the HTTP status itself, rather than the status header. Apologies if this caused downtime for you, this was an unfortunate side effect on the upgrade and not how we would usually announce breaking changes. I’ve noticed some libraries making the required changes for this. Is this a feasible approach for the library that you’re using?

As for the documentation, thank you for flagging the inconsistency there. We’ll be updating the docs to reflect the recent changes.

1 Like
#6

Hi @imwiss Thank you for a really great answer!
In our team we’ve now made some local changes in our build chain to overcome this problem, which is a short term solution we can live with. The long time solution is to abandon this library.

Even though it’s not a solution, we now know why it stopped working, and we’ve been able to solve it.
Thank you for your time!

1 Like