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.
I'm getting errors when attempting to build with any older version:
golang.org/x/term
# golang.org/x/term
../../../golang.org/x/term/term_unix_linux.go:9:7: ioctlReadTermios redeclared in this block
previous declaration at ../../../golang.org/x/term/term_unix_aix.go:9:26
../../../golang.org/x/term/term_unix_linux.go:10:7: ioctlWriteTermios redeclared in this block
previous declaration at ../../../golang.org/x/term/term_unix_aix.go:10:27
The XML marahaller will attempt to marshal the top-level elements, not
knowing that the lower-level elements are empty. Making them pointers
solves this.
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.
