http://bugs.winehq.org/show_bug.cgi?id=18384
--- Comment #32 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-05-31 16:52:03 --- (In reply to comment #31)
The content-type is x-www-urlencoded, but I'm still seeing spaces and '@' symbols, could those be causing an issue? Or is the encoding done later?
Stripping anything other than [a-z0-9] from names/values doesn't have an effect. Seems like their script itself is refusing the request - with the patch the request looks perfectly valid.
(In reply to comment #30)
Amusingly, dumping an HTTP log from a Windows machine is proving hard, as I can't seem to find a way to inject a listener before the request is SSL-ified.
Hmmm, well if you can't dump a log, try writing a small windows app that just repeats the calls that were done, except make it point to http and not https. That way we can (somewhat) know what is being sent.
Just read this - Maybe you can connect to https and use HttpQueryInfoW with HTTP_QUERY_FLAG_REQUEST_HEADERS | HTTP_QUERY_RAW_HEADERS_CRLF to get the request headers wininet generates. This might not give you the data though, but it'll let you see if windows adds some ssl-specific headers.
Last idea - modify your hosts file and point it to localhost. Then run some fake-ish server that just echos the request and does nothing else.