-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ESP8266WebServer does not handle special characters in JSON body #2198
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
Comments
Need to check this together with #1989. |
@liquidfalcon issue should be fixed now. Can you please confirm? |
So, the commits fix the first issue, which was with the plus symbol, but, it still picks up on others, such as the Ampersand, and cuts the payload after that. For example, here is what I send: And this is what I receive for plain |
can you please paste the full request that you are sending so I can test it here? |
Of course - Here's the raw request I tested with using cURL:
Command: |
great! will do |
btw totally different issues :) first was urldecode and here it's trying to parse parameters, which it should not |
Fixed! The whole text is copied on it's own without ever being parsed, decoded or anything else.
|
You're a legend mate, thank you! |
* fix urlDecode points Fixes: esp8266/Arduino#1989 esp8266/Arduino#2198 * Add missing separator between get and plain post arguments
Regardless of whether the body is set as plain or application/json, _parseArguments will always perform URL decoding on it, leading to unexpected results.
Example JSON sent:
After receiving it through ESP8266WebServer
Currently it makes it so no JSON can include a plus sign, or any other symbol the URL decoder will pick up.
EDIT: Incidentally, including something like this completely breaks input:
{ "ssid":"SSID+&(!@","psk":"@#$%^&+" }
Double EDIT:
A super simple if else block like this works around it for now:
I plan to modify it to include the option to retrieve the raw body payload if the content-type is equal to application/json, and not call _parseArguments. Would you be interested in this as a pull request once this is complete? I think this is the most sensible way to handle JSON data, otherwise it seems to be a bit of a hack to run it past something expecting url/form encoded data.
The text was updated successfully, but these errors were encountered: