Form not sent with same semantics as FormBody

[Bilge]

I apologise I haven't been able to reduce this down to a simpler test case, but it seems very clear to me that something is not right when sending Form in beta 11 as with FormBody from the previous API iteration. I haven't been able to narrow down exactly what is different between the two requests, but I can reliably reproduce it with a test.

To test this, please try running SteamLoginTest::testSecureLoginCookie, which requires STEAM_USER and STEAM_PASSWORD to be set to a valid Steam username and password (you can get an account for free).

master will work, but switching over to connectors-v7, which has minimal changes, will fail on SteamLogin:99 with {"response":{"interval":5,"extended_error_message":""}}. Unfortunately this opaque error is all we have to work with.

[kelunik]

Some more info would be really helpful. Can you log the full bodies and do a diff there?

[Bilge]

I don't know where to capture the full body. Maybe I'll try some hardcore debugging later.

[Bilge]

OK I went hardcore, by placing a breakpoint deep within Http2ConnectionProcessor::request, and I found that the old (working) code would escape form field content whereas the new (broken) code does not.

For example, base64 characters such as + and / appear verbatim in the new, broken code whereas they are percent-encoded as %2B and %2F, respectively, in the old, working code. So that's probably the issue.

Note the headers are the same in both cases (in particular, content-type is application/x-www-form-urlencoded).

Moreover, note that I cannot manually escape the content because it will encode % signs to %25, causing them to become double-escaped and thus still fail.

[kelunik]

See also amphp/http#24.