Section 4.2.2.2 Type 1 Protocol Overview in the
[Open Financial Exchange Specification 2.2, Nov 26, 2017](https://www.ofx.net/downloads/OFX%202.2.pdf)
states that:
Type 1 applies only to the request part of a message; the server response is unaffected.
Thus it appears that we can safely parse SECURITY:TYPE1
using the same logic that we parse SECURITY:NONE
As I understand it, Security:TYPE1 indicates that the
financial institution uses SSL enryption to protect
customer credentials in transit. This applies
explicitly to the incoming requests which may
contain authentication as part of the request
but does not appear to cause any material changes
to the response format.
As a result it appears that we can safely parse
SECURITY:TYPE1 responess in the same way that
we parse SECURITY:NONE responsese.
Some financial institutions (*cough* Wells Fargo *cough*) export OFX files as a single line, which is technically valid according to the v1 spec. In order to parse them correctly, `readSGMLHeaders` now uses a regular expression that allows for all whitespace/line breaks to be optionally excluded.
A new sample response (wellsfargo.qfx) has been added to document this behaviour.
Detect when a newline doesn't follow the last header when parsing SGML and break out of the header-parsing loop early. Add an example .qfx file demonstrating the broken behavior we're working around and a test.
David Alpert
Aaron Ross
Martin Kobetic
Aaron Lindsay