WebRequest bug - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
In Chrome:
Request1:
Response1:
Request2:
Response2:
Both WebRequest calls will result in (from Fiddler):
Cache-Control: no-cache
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/plain
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Charset: *,utf-8
Accept-Language: en
Host: mql-crypt.herokuapp.com
User-Agent: MetaTrader 4 Terminal/4.1260 (Windows NT 10.0; x64)
And web server will return the same response as:
(
[param1] => Na6dIwFMr4weGnRNTYewxrpffSiYDhl0un02dGYEMv1lThKoYuUEk1Q Dmfk477k
)
What is this server ?
Why is it answering "Na6dIwFMr4weGnRNTYewxrpffSiYDhl0un02dGYEMv1lThKoYuUEk1Q Dmfk477k" to a request with "Na6dIwFMr4weGnRNTYewxrpffSiYDhl0un02dGYEMv1lThKoYuUEk1Q+Dmfk477.
Confirmed Bug.
You can easily setup an echo-server in docker.
docker-compose.yaml
docker-compose -f docker-compose.yaml up
simple test script
Echo results: first using python then MT5
my-http-listener_1 | ----------------- my-http-listener_1 | { path: '/hello-world', my-http-listener_1 | headers: my-http-listener_1 | { host: 'localhost', my-http-listener_1 | 'user-agent': 'python-requests/2.23.0', my-http-listener_1 | 'accept-encoding': 'gzip, deflate', my-http-listener_1 | accept: '*/*', my-http-listener_1 | connection: 'keep-alive' }, my-http-listener_1 | method: 'GET', my-http-listener_1 | body: '', my-http-listener_1 | cookies: undefined, my-http-listener_1 | fresh: false, my-http-listener_1 | hostname: 'localhost', my-http-listener_1 | ip: '::ffff:172.17.0.1', my-http-listener_1 | ips: [], my-http-listener_1 | protocol: 'http', my-http-listener_1 | query: { query: 'test 1+2' }, my-http-listener_1 | subdomains: [], my-http-listener_1 | xhr: false, my-http-listener_1 | connection: { servername: undefined } } my-http-listener_1 | "GET /hello-world?query=test+1%2B2 HTTP/1.1" my-http-listener_1 | ----------------- my-http-listener_1 | { path: '/', my-http-listener_1 | headers: my-http-listener_1 | { host: '127.0.0.1', my-http-listener_1 | accept: '*/*', my-http-listener_1 | 'accept-encoding': 'gzip, deflate', my-http-listener_1 | 'accept-language': 'en', my-http-listener_1 | 'user-agent': 'MetaTrader 5 Terminal/5.2450 (Windows NT 10.0; x64)', my-http-listener_1 | connection: 'keep-alive', my-http-listener_1 | 'content-length': '0' }, my-http-listener_1 | method: 'GET', my-http-listener_1 | body: '', my-http-listener_1 | cookies: undefined, my-http-listener_1 | fresh: false, my-http-listener_1 | hostname: '127.0.0.1', my-http-listener_1 | ip: '::ffff:172.17.0.1', my-http-listener_1 | ips: [], my-http-listener_1 | protocol: 'http', my-http-listener_1 | query: { query: 'test 1 2' }, my-http-listener_1 | subdomains: [], my-http-listener_1 | xhr: false, my-http-listener_1 | connection: { servername: undefined } } my-http-listener_1 | "GET /?query=test+1+2 HTTP/1.1"Confirmed Bug.
You can easily setup an echo-server in docker.
docker-compose.yaml
docker-compose -f docker-compose.yaml up
simple test script
Echo results: first using python then MT5
Why confirmed ?
It's confirmed that WebRequest() change the '%2B' to a '+', but why is that a bug ?
And subsidiary question why is the server converting the '+' to a space ?
Why confirmed ?
It's confirmed that WebRequest() change the '%2B' to a '+', but why is that a bug ?
And subsidiary question why is the server converting the '+' to a space ?
The url has to be encoded before sending a request to the server. It confirms that WebRequests is taking an already url-encoded string, parsing it, then incorrectly re-encoding it before sending it to the server. To answer your second question, the echo-server takes the url encoded query string and converts it back to utf-8 machine readable string when echoing it as JSON. Here's an example you can run in a python shell.
This is how it should work, and also how it's not being done in webrequests.
I forgot to add...
This is what WebRequests is doing to the string which is incorrect.
>>> q = q.replace('%2B', '+') >>> parse.parse_qsl(q) [('query', 'Test 1 2')]Furthermore... you can also see the exact string being received by the server from both requests test.
The url has to be encoded before sending a request to the server. It confirms that WebRequests is taking an already url-encoded string, parsing it, then incorrectly re-encoding it before sending it to the server. To answer your second question, the echo-server takes the url encoded query string and converts it back to utf-8 machine readable string when echoing it as JSON. Here's an example you can run in a python shell.
WebRequest is doing some decoding/encoding. We all agree on that. And it should at least be documented. But that was not my point.
The point could be summarized as : Why "it's how it should work" ? I found my answer :
I was searching in the standard, and of course didn't found it.
So it's a WebRequest "bug" because the HTTP servers don't follow the standards ( The standard says '+' should not be encoded). And we all know how Metaquotes is respectful about the standards.
I found my answer :
I was searching in the standard, and of course didn't found it.
Webservers accept url-encoded strings. WebRequests' url parameter takes a string that's already url-encoded. WebRequests url param should not be mucking about with the encoded string. I'm not sure you are understanding even though everyone ITT is providing very simple MCVE. MQ is not respectful of the "standards" in these regards. MQ is taking a taking a properly encoded string and forwarding it to the webserver as a different (improperly encoded) string. That is a bug.
What is this server ?
Why is it answering "Na6dIwFMr4weGnRNTYewxrpffSiYDhl0un02dGYEMv1lThKoYuUEk1Q Dmfk477k" to a request with "Na6dIwFMr4weGnRNTYewxrpffSiYDhl0un02dGYEMv1lThKoYuUEk1Q+Dmfk477.