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.
