okomestudio / mime-streamer Goto Github PK

Currently, non-XOP response isn't gracefully handled when XOPResponseStreamer is initialized with one:

    xop = XOPResponseStreamer(resp)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <XOPResponseStreamer>, resp = <Response [500]>

    def __init__(self, resp):
        super(XOPResponseStreamer, self).__init__(resp)
>       if self._ct_params['mime-type'].lower() != 'multipart/related':
E       AttributeError: 'XOPResponseStreamer' object has no attribute '_ct_params'

../../../.virtualenvs/ingester/local/lib/python2.7/site-packages/mime_streamer/mime_response_streamer.py:110: AttributeError

Add more informative message when this happens.

This would be useful when flushing the read content is desired when an error is encountered while stream parsing the content. Perhaps add an optional argument to get_next_part to switch the behavior within the context manager.

It's about time...

Also add instruction for running tests with Docker.

Multipart document can mix different newline sequence, e.g., the envelope assumes \r\n as the canonical newline but content body embedded within a part can be multiline content delimited with \n. In such a case, iter_lines does not delimit on \n, making stream-reading continue on until the full body is ready, which is a problem when the body is huge.

Fix it so that lines are constructed generically on any valid newline, but be careful to keep the newline actually used (i.e., do not assume all lines are delimited by \r\n as in multipart message spec) and not to modify the actual byte sequence.