{"action":"created","issue":{"url":"https://api.github.com/repos/rubygems/rubygems.org/issues/1652","repository_url":"https://api.github.com/repos/rubygems/rubygems.org","labels_url":"https://api.github.com/repos/rubygems/rubygems.org/issues/1652/labels{/name}","comments_url":"https://api.github.com/repos/rubygems/rubygems.org/issues/1652/comments","events_url":"https://api.github.com/repos/rubygems/rubygems.org/issues/1652/events","html_url":"https://github.com/rubygems/rubygems.org/pull/1652","id":239330448,"node_id":"MDExOlB1bGxSZXF1ZXN0MTI4MDQ0NTEz","number":1652,"title":"Return 304 not modified when ETag matches on CompactIndex versions requests","user":{"login":"greysteil","id":1144873,"node_id":"MDQ6VXNlcjExNDQ4NzM=","avatar_url":"https://avatars0.githubusercontent.com/u/1144873?v=4","gravatar_id":"","url":"https://api.github.com/users/greysteil","html_url":"https://github.com/greysteil","followers_url":"https://api.github.com/users/greysteil/followers","following_url":"https://api.github.com/users/greysteil/following{/other_user}","gists_url":"https://api.github.com/users/greysteil/gists{/gist_id}","starred_url":"https://api.github.com/users/greysteil/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/greysteil/subscriptions","organizations_url":"https://api.github.com/users/greysteil/orgs","repos_url":"https://api.github.com/users/greysteil/repos","events_url":"https://api.github.com/users/greysteil/events{/privacy}","received_events_url":"https://api.github.com/users/greysteil/received_events","type":"User","site_admin":false},"labels":[{"id":509334936,"node_id":"MDU6TGFiZWw1MDkzMzQ5MzY=","url":"https://api.github.com/repos/rubygems/rubygems.org/labels/needs-review","name":"needs-review","color":"FFB6C1","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-06-28T23:57:25Z","updated_at":"2019-01-04T17:55:51Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/rubygems/rubygems.org/pulls/1652","html_url":"https://github.com/rubygems/rubygems.org/pull/1652","diff_url":"https://github.com/rubygems/rubygems.org/pull/1652.diff","patch_url":"https://github.com/rubygems/rubygems.org/pull/1652.patch"},"body":"Previously, there was no ETag checking for calls to `https://index.rubygems.org/versions`. That was particularly sad for Bundler, as it caused the following flow:\r\n1. Bundler requests `https://index.rubygems.org/versions`, gets the latest `versions` file, and caches it\r\n2. Bundler wants to check for updates to the `versions` file. It submits another request to `https://index.rubygems.org/versions` with the correct ETag, asking only for bytes after the final byte of its current `versions` file\r\n3. EITHER the `version` file had changed, and bundler received the extra bytes successfully (happy case)\r\n4. OR the `version` file had not changed. In this case the ETag was ignored and a range response was still requested. But as the file hadn't changed, the content of this range response would be empty, and would trigger a `416` response. Bundler would treat this as a `Bundler::HTTPError` and give up fetching the CompactIndex, opting for the dependencies index instead.\r\n\r\nI'll put a PR in to Bundler to handle 416 errors more sensibly, too."},"comment":{"url":"https://api.github.com/repos/rubygems/rubygems.org/issues/comments/451518740","html_url":"https://github.com/rubygems/rubygems.org/pull/1652#issuecomment-451518740","issue_url":"https://api.github.com/repos/rubygems/rubygems.org/issues/1652","id":451518740,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTUxODc0MA==","user":{"login":"sonalkr132","id":7680662,"node_id":"MDQ6VXNlcjc2ODA2NjI=","avatar_url":"https://avatars0.githubusercontent.com/u/7680662?v=4","gravatar_id":"","url":"https://api.github.com/users/sonalkr132","html_url":"https://github.com/sonalkr132","followers_url":"https://api.github.com/users/sonalkr132/followers","following_url":"https://api.github.com/users/sonalkr132/following{/other_user}","gists_url":"https://api.github.com/users/sonalkr132/gists{/gist_id}","starred_url":"https://api.github.com/users/sonalkr132/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sonalkr132/subscriptions","organizations_url":"https://api.github.com/users/sonalkr132/orgs","repos_url":"https://api.github.com/users/sonalkr132/repos","events_url":"https://api.github.com/users/sonalkr132/events{/privacy}","received_events_url":"https://api.github.com/users/sonalkr132/received_events","type":"User","site_admin":false},"created_at":"2019-01-04T17:55:51Z","updated_at":"2019-01-04T17:55:51Z","author_association":"MEMBER","body":"> If a valid byte-range-set includes at least one byte-range-spec (`229-`) with\r\n   a first-byte-pos (`229`) that is less than the current length of the\r\n   representation, or at least one suffix-byte-range-spec with a\r\n   non-zero suffix-length, then the byte-range-set is satisfiable.\r\n   Otherwise, the byte-range-set is unsatisfiable.\r\n   [RFC 7233](https://tools.ietf.org/html/rfc7233)\r\n\r\nThis is expected behaviour as per the RFC on Range Requests.\r\nHowever, as [this stackoverflow answer](https://stackoverflow.com/questions/3303029/http-range-header#answer-18745164) points out making range request where there is no more content to fetch is an valid/expected use case for a client.\r\n\r\nNote: SO answerer linked above hails citation of the fact that RFC example says, `bytes=9500-` is valid request and hence contradicting itself. It is not..the example in question is:\r\n> Additional examples, assuming a representation of **length 10000** :\r\n   o  The final 500 bytes (byte offsets 9500-9999, inclusive):\r\n        bytes=-500\r\n   Or:\r\n        bytes=9500-\r\n"}}
{"actor":{"display_login":"sonalkr132"}}