{"action":"created","issue":{"url":"https://api.github.com/repos/olalonde/follow-redirects/issues/19","labels_url":"https://api.github.com/repos/olalonde/follow-redirects/issues/19/labels{/name}","comments_url":"https://api.github.com/repos/olalonde/follow-redirects/issues/19/comments","events_url":"https://api.github.com/repos/olalonde/follow-redirects/issues/19/events","html_url":"https://github.com/olalonde/follow-redirects/issues/19","id":92967469,"number":19,"title":"Create optimal cross-platform development experience via browserify.","user":{"login":"jamestalmage","id":4082216,"avatar_url":"https://avatars.githubusercontent.com/u/4082216?v=3","gravatar_id":"","url":"https://api.github.com/users/jamestalmage","html_url":"https://github.com/jamestalmage","followers_url":"https://api.github.com/users/jamestalmage/followers","following_url":"https://api.github.com/users/jamestalmage/following{/other_user}","gists_url":"https://api.github.com/users/jamestalmage/gists{/gist_id}","starred_url":"https://api.github.com/users/jamestalmage/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamestalmage/subscriptions","organizations_url":"https://api.github.com/users/jamestalmage/orgs","repos_url":"https://api.github.com/users/jamestalmage/repos","events_url":"https://api.github.com/users/jamestalmage/events{/privacy}","received_events_url":"https://api.github.com/users/jamestalmage/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-07-04T03:49:44Z","updated_at":"2015-07-04T13:17:29Z","closed_at":null,"body":"I think `follow-redirects` _default_ behavior should be to mimic the behavior of the `http` and `https` as used in the browser via `browserify`. `XMLHtppRequest` follows redirects transparently, and there is no way to disable that. Therefore the browserified versions of `http` and `https` automatically have a `follow-redirects` like behavior, but the server side counterparts do not (obviously, there would be little point to this module otherwise). However, this behavior breaks one of the key goals of `browserify`; the ability to write code that behaves identically on the client and server. This isn't the fault of browserify, due to the way `XMLHttpRequest` behaves they can't possibly emulate the behavior of the native modules.\r\n\r\nI am definitely *not* suggesting we turn `follow-redirects` into a client side library, but instead help the _server_ behave more like the _client_. This is backwards from the goal of most browserify modules, but as previously stated, it's just not possible to emulate the server in this case. Developers seeking to create a cross platform solution would use `follow-redirects` on the server, and have browserify automatically swap it out with `browserify-http` when creating the client bundle. Indeed, I have already detailed instructions for doing just that in the README.\r\n\r\nWe are already very close. For many scenarios the library will work as is. However, there are still a few points to be addressed.\r\n\r\n 1. Issue #12 needs to be fixed. Specifically, our current logic for deciding when to redirect is pretty basic. It's not always OK to redirect for every `300` level code. The [spec](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) notes many scenarios where typical browser behavior is actually not to spec. Rather than strictly conforming to the spec, we should follow whatever the most common behavior is. \r\n 2. Also related to #12, we currently always perform a `GET` on redirection, even if the original request was a `POST` or otherwise. This is the correct response in most situations, but (I believe) not all. \r\n 3. Handling errors. Currently we emit an error on the returned client request object if we exceed the maximum number of redirects. We also forward any errors we encounter on subsequent redirected requests to the original one.  If we encounter a `3XX` status code without a `Location` header, we do not throw an error, but return the result to the registered callback. This all makes logical sense, but we should work to make our behavior the same as the client side modules.\r\n 4. Make all this configurable. There is already an (optional and as yet undocumented) `makeRequest` callback that allows us to change these behaviors on master. It's probably wise to keep a \"legacy\" version of that callback around that continues to mimic the behavior of the library as it has existed for years.\r\n 5. We should do all this while still maintaining API compatibility with the core modules (nodes native `http` and `browserify-http`, etc). Plenty of cross-platorm options exist if you are willing to deal with a different API. The goal here should be an easy transitions for those using the core modules.\r\n 6. Be as lightweight on the client side as possible. Ideally, this means not existing at all on the client, and instead differing to the core `browserify` implementations that are likely already bundled."},"comment":{"url":"https://api.github.com/repos/olalonde/follow-redirects/issues/comments/118511823","html_url":"https://github.com/olalonde/follow-redirects/issues/19#issuecomment-118511823","issue_url":"https://api.github.com/repos/olalonde/follow-redirects/issues/19","id":118511823,"user":{"login":"bendrucker","id":808808,"avatar_url":"https://avatars.githubusercontent.com/u/808808?v=3","gravatar_id":"","url":"https://api.github.com/users/bendrucker","html_url":"https://github.com/bendrucker","followers_url":"https://api.github.com/users/bendrucker/followers","following_url":"https://api.github.com/users/bendrucker/following{/other_user}","gists_url":"https://api.github.com/users/bendrucker/gists{/gist_id}","starred_url":"https://api.github.com/users/bendrucker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bendrucker/subscriptions","organizations_url":"https://api.github.com/users/bendrucker/orgs","repos_url":"https://api.github.com/users/bendrucker/repos","events_url":"https://api.github.com/users/bendrucker/events{/privacy}","received_events_url":"https://api.github.com/users/bendrucker/received_events","type":"User","site_admin":false},"created_at":"2015-07-04T13:17:29Z","updated_at":"2015-07-04T13:17:29Z","body":"I like this. I personally use https://github.com/sindresorhus/got quite heavily and it follows redirects. But it's not 100% identical when browserified and I think there's room for a module that is and sits at a lower level. "}}