Unexpected result in iter_lines with '\r\n' delimiter

With this test case (named `request_iter_lines_test.py`):
```
import unittest
import requests
from io import StringIO


class TestIterLines(unittest.TestCase):

    def iter_lines_response(self, chunk_size, delimiter=None):
        response = requests.Response()
        response.raw = StringIO('01\r\n45')
        gen = response.iter_lines(chunk_size=chunk_size, delimiter=delimiter)
        result = list(gen)
        self.assertEqual(result, ['01', '45'])

    def test_splitlines_before_delimiter(self): self.iter_lines_response(2)

    def test_splitlines_in_delimiter(self): self.iter_lines_response(3)

    def test_splitlines_after_delimiter(self): self.iter_lines_response(4)

    def test_splitlines_in_line(self): self.iter_lines_response(5)

    def test_split_before_delimiter(self): self.iter_lines_response(2, '\r\n')

    def test_split_in_delimiter(self): self.iter_lines_response(3, '\r\n')

    def test_split_after_delimiter(self): self.iter_lines_response(4, '\r\n')

    def test_split_in_line(self): self.iter_lines_response(5, '\r\n')
```

when running:

`python3 -m unittest request_iter_lines_test.py`

It should finish without any errors. Instead if fails with 3 errors.

When there is a delimiter, this patch (for Fedora) corrects the problems,
```
--- /usr/lib/python3.5/site-packages/requests/models.py.orig	2017-02-01 16:04:02.117318286 -0200
+++ /usr/lib/python3.5/site-packages/requests/models.py	2017-02-01 16:53:15.219410425 -0200
@@ -707,16 +707,29 @@
 
             if pending is not None:
                 chunk = pending + chunk
+                pending = None
 
             if delimiter:
+                wrap = False
+                for i in range(1, len(delimiter) + 1):
+                    if chunk.endswith(delimiter[:i]):
+                        wrap = True
+                        break
+                if wrap:
+                    if pending is not None:
+                        pending = pending + chunk
+                    else:
+                        pending = chunk
+                    continue
                 lines = chunk.split(delimiter)
             else:
                 lines = chunk.splitlines()
 
             if lines and lines[-1] and chunk and lines[-1][-1] == chunk[-1]:
-                pending = lines.pop()
-            else:
-                pending = None
+                if pending is not None:
+                    pending = pending + lines.pop()
+                else:
+                    pending = lines.pop()
 
             for line in lines:
                 yield line
```

but it is incomplete, as the test case fails when a delimiter is not specified, lines are separated by `'\r\n'` and the text chunk ends in the middle of the sequence, that is, ends in `'\r'` and next chunk starts with `'\n'`. So, `chunk.splitlines()` possibly needs to override `TextIOWrapper` logic in this condition.


Yeah, this function definitely needs more work. I agree that the Fedora patch is incomplete: I also worry that it doesn't correctly handle the possibility of repeated sequences of delimiters, which *should* emit empty lines.

Anyone interested in contributing should feel free to pick this up. I recommend using the test cases above as examples to guide your work, and I also recommend writing substantially more to help verify all these edge cases.

As a (potential) contributor looking into this, could it be clarified what Fedora has to do with this bug? I'm not understanding what is meant by the above patch being a "Fedora patch".

Hey @e-beach, thanks for your interest in contributing. This isn't an issue specific to Fedora, I believe that @pcpa is either referring to a patch already implemented by the Fedora team, or one they've written against Fedoras distribution of Requests.

That said, I'm not sure we actually need a patch here @Lukasa. I believe this was already addressed on the 3.0.0 branch with #3984.

The tests @pcpa wrote on the fail on the 3.0.0 branch with TypeErrors, which is different than the previous error, and indicates that the 3.0.0 API is not compatible with the proposed test. Hence this looks to me like this a non-issue, or at least not contributor-friendly :confused: 

Hmm, so this is because we're passing a non-BytesIO object as raw and the 3.0.0 patch assumes we're dealing in bytes. I believe that's a reasonable assumption since it's what we'll get from urllib3 but I may be missing something.

I switched the code to the new form using bytes instead of strings at this [gist]( https://gist.github.com/e-beach/d17e2af653b71c97174c53f86e67214b), and all tests passed.
I'd say this issue could be closed.

Cool, works for me. Thanks for digging @e-beach and @nateprewitt!