{"action":"created","issue":{"url":"https://api.github.com/repos/kennethreitz/requests/issues/2645","repository_url":"https://api.github.com/repos/kennethreitz/requests","labels_url":"https://api.github.com/repos/kennethreitz/requests/issues/2645/labels{/name}","comments_url":"https://api.github.com/repos/kennethreitz/requests/issues/2645/comments","events_url":"https://api.github.com/repos/kennethreitz/requests/issues/2645/events","html_url":"https://github.com/kennethreitz/requests/issues/2645","id":89629370,"number":2645,"title":"[RFC] Change behaviour of Response.ok in 3.0","user":{"login":"sigmavirus24","id":240830,"avatar_url":"https://avatars.githubusercontent.com/u/240830?v=3","gravatar_id":"","url":"https://api.github.com/users/sigmavirus24","html_url":"https://github.com/sigmavirus24","followers_url":"https://api.github.com/users/sigmavirus24/followers","following_url":"https://api.github.com/users/sigmavirus24/following{/other_user}","gists_url":"https://api.github.com/users/sigmavirus24/gists{/gist_id}","starred_url":"https://api.github.com/users/sigmavirus24/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sigmavirus24/subscriptions","organizations_url":"https://api.github.com/users/sigmavirus24/orgs","repos_url":"https://api.github.com/users/sigmavirus24/repos","events_url":"https://api.github.com/users/sigmavirus24/events{/privacy}","received_events_url":"https://api.github.com/users/sigmavirus24/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-06-19T18:29:16Z","updated_at":"2016-05-16T04:02:01Z","closed_at":null,"body":"# Preamble\r\n\r\nPlease note that this a request for comments, not something that we will *definitely* do in Requests.\r\n\r\n# Problem\r\n\r\nRight now we have an attribute defined on a Response object, ``ok``. This attribute [currently](https://github.com/kennethreitz/requests/blob/9bbab338fdbb562b923ba2d8a80f0bfba697fa41/requests/models.py#L617..L623) calls ``self.raise_for_status()`` and catches the [exception](https://github.com/kennethreitz/requests/blob/9bbab338fdbb562b923ba2d8a80f0bfba697fa41/requests/models.py#L825..L837) raised. ``raise_for_status`` appropriately only raises an exception for status codes in the 4xx or 5xx range. This means that a Response with a status code in the 2xx and 3xx range will be \"ok\". The problem is that \"ok\" has a certain association in HTTP with 2xx responses, specifically 200 responses. This *may* (I haven't looked to see if anyone has had problems with this) be misleading, especially if the user is combining their usage of the ``ok`` attribute with ``allow_redirects=False``.\r\n\r\n# Proposed Solution\r\n\r\nInstead of using ``raise_for_status`` to determine the \"ok-ness\" of a response, we should compare the status code of the response directly. This will do two things:\r\n\r\n1. It will narrow the definition of ``Response.ok``\r\n1. It will make using ``Response.ok`` faster. Currently we add a new stack, potentially throw and catch an exception, and then return. With a simple comparison, we could just do: `return 200 <= self.status_code < 300` which is much faster. This argument, however, doesn't hold much weight for me personally.\r\n\r\nI'd really love @Lukasa and @kennethreitz's opinions here as well as anyone else willing to share their opinion publicly."},"comment":{"url":"https://api.github.com/repos/kennethreitz/requests/issues/comments/219344177","html_url":"https://github.com/kennethreitz/requests/issues/2645#issuecomment-219344177","issue_url":"https://api.github.com/repos/kennethreitz/requests/issues/2645","id":219344177,"user":{"login":"Itwilloutliveyou","id":15115673,"avatar_url":"https://avatars.githubusercontent.com/u/15115673?v=3","gravatar_id":"","url":"https://api.github.com/users/Itwilloutliveyou","html_url":"https://github.com/Itwilloutliveyou","followers_url":"https://api.github.com/users/Itwilloutliveyou/followers","following_url":"https://api.github.com/users/Itwilloutliveyou/following{/other_user}","gists_url":"https://api.github.com/users/Itwilloutliveyou/gists{/gist_id}","starred_url":"https://api.github.com/users/Itwilloutliveyou/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Itwilloutliveyou/subscriptions","organizations_url":"https://api.github.com/users/Itwilloutliveyou/orgs","repos_url":"https://api.github.com/users/Itwilloutliveyou/repos","events_url":"https://api.github.com/users/Itwilloutliveyou/events{/privacy}","received_events_url":"https://api.github.com/users/Itwilloutliveyou/received_events","type":"User","site_admin":false},"created_at":"2016-05-16T04:02:01Z","updated_at":"2016-05-16T04:02:01Z","body":"The solution proposed is to add a success attribute listing all the status codes that are considered ok (200, 201, 202, ..., 226). Then, we compare the status code of the response with the ones listed in success.\r\n\r\nWhat happens is that the response for a 301 redirect, for example, is a status code 200. The same happens for other status codes of the 3xx family. @sigmavirus24 came with the idea that one of the reasons for that change is to narrow the definition of Response.ok. If that's the case, wouldn't it be better to rethink the outcome of those 3xx cases?"}}