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.
This allows for ofxgo to be used to create well-formatted OFX from poor
OFX, or even be used to generate OFX from other formats for easier
importing into financial management software.
Test this functionality by adding "round trip" testing to all existing
tests - ensure that responses' content is the same after a round trip of
marshalling and unmarshalling them.
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.
This removes the many decodeXXXMessageSet() functions and replaces them
with a large map and a single generic decodeMessageSet() function. Also
change Responses to satisfy the Message interface as pointer types
(instead of the raw types), add the full set of top-level message sets
(though most of them still lack any message-parsing ability), adjust the
message set names to more closely mirror their OFX names, and fixup
tests and the command-line client to match the above changes.
David Alpert
Aaron Ross
John Starich
Aaron Lindsay
Martin Kobetic