-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
amex broken under requests but not urllib #162
Comments
Nice catch, thanks for reporting. Should be fixed in 655549a |
Actually, not sure that's it, though removing |
No your're right, it's probably not. If you search |
I managed to reproduce this with curl; it's pretty wacky, and seems to to do with header ordering: OK: Forbidden: |
The
You can work around this by setting headers on session, i.e. Forbidden: OK: And for reference, what urllib sends (also OK): |
You're in it to win it! Whatever homegrown jank Amex has up on the web seems to be in the van of the "code to Quicken not the spec" movement. If you're hardcore, you'll want to install Quicken & mitmproxy to directly observe the header sequence being set by the genuine article, rather than repeatedly lobbing codebreaker style guesses at their server. But if you want to break up the code behind the But, and I'm gonna keep bringing this up, you could also just avoid using requests, by running ofxtools in a virtual env that doesn't have requests installed. Everything about OFX download is fairly terrible, and there's just not that much life left in the system over which to amortize a bunch of dev work. |
Yeah, I ended up just setting |
When using requests, content type is sent as "Content-type" while urllib sends "Content-Type". Per https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.5, the latter is correct. This evidently breaks amex starting a couple days ago.
The text was updated successfully, but these errors were encountered: