Some problems with /send parameters encoding

[ikey-ru]

Hi! As described in HTML standard, when we are passing values as post content-value pairs we should use following approach:

application/x-www-form-urlencoded
This is the default content type. Forms submitted with this content type must be encoded as follows:

• Control names and values are escaped. Space characters are replaced by '+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by '%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., '%0D%0A').
• The control names/values are listed in the order they appear in the document. The name is separated from the value by '=' and name/value pairs are separated from each other by '&'. Source: https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4

However, SMS server expects POST data in RFC3986 format (space replaced by %20 and some other differences).

Possible solutions:

1. Change POST parameters encoding to RFC1738, as it should be.
2. Clearly define at API.md at /send section that POST parameters should be encoded in RFC3986 format (not the best solution).

[itsjunetime]

Thank you for bringing this to my attention — to be completely honest, I wasn't aware that there were specific formats for post data formatting, so I'm glad you brought this up. It seems that RFC1738 is the expected format, so I'll try to rewrite the sections of my code that send to and handle requests through the /send subdirectory. However, since this will probably require a good amount of time, I can't guarantee when it'll be done. I'll update this task as I work through it or run into any issues with this format.

[itsjunetime]

So recently, when I got time to check out this issue more, I realized that (if I'm not mistaken), all the HTML forms in the web interface are encoded as multitype/form-data (as you can see in lines 1290 and 1302 of src/SMServer/html/chats.html). Due to this, these forms need not conform to RFC1738, but rather to RFC2045 (which I'm fairly certain they already correctly conform to), so I need not change the API at all to remedy this. If you think this is not the case or that I am mistaken about something, please let me know. Otherwise, feel free to close this issue.

[itsjunetime]

This issue has been stale for a while, and the issue is resolved to the best of my knowledge. Closing.