Testing REST - submitting a web-form. Identifying why the server responses with 500 for some emails and for some - 200

Question

The troubled email is [email protected], the URL is https://junior.skyeng.ru/online-uroki-po-matematike/ (form is placed almost at footer).

The website to test is in Russian. If you want to help me - please translate it in Chrome, it's easy. Or you just go directly to Postman:

POST https://crm.skyeng.ru/order/createV2Kid
Body(x-www-form-urlencoded):
parentName: test
parentEmail: [email protected]
parentPhone: +79650389823 (any decent Russian mobile phone)
subject: mathematics
childName: test

So the response is 500 Internal Server Error. The task here is to localize the error. To find out the specific conditions why the bug occurs.

What I've done (just some of examples):

[email protected]
x-www-form-urlencoded
200 ok

[email protected]
x-www-form-urlencoded
500

[email protected]
x-www-form-urlencoded
200

[email protected]
x-www-form-urlencoded
500

And if you change from x-www-form-urlencoded to form-data it will return every request with 200 OK, even with our email [email protected].

So my questions are:

• Is it really happening because of x-www-form-urlencoded? If so, why then we are able to get 200 Ok with [email protected] and any other real email?
• Maybe we should look at some Headers or other additional information and if yes - where exactly?

I can't even google anything because I don't know exactly what to find. I googled articles about form-data/x-www-form-urlencoded, HTTP (https://developer.mozilla.org/en-US/docs/Web/HTTP) and still can't localize the bug.

I would appreciate any help!

Answer 1

Your testing is good. You are considering different possibilities and conducting experiments to see what happens. That is great.

I would continue that process. Here are some thoughts for you to try out. They are not answers you can copy and paste (which, as you indicate is good), they are ideas for your to try out yourself. Good luck!

• Try special characters, numbers and letters, underscores 'as is'
• Try special character that are encoded, e.g. &nbsp for space
• Try different input lengths
• Use an email that was created today
• Use an email that you know doesn't exist
• Use an accepted email then try a second time with same email and record error
• Timing - try quick and slow data entry
• Javascript - try disabling javascript
• Browser errors - see chrome console for any errors, such as network

In some of the above cases, the details of the error may help point you towards the cause

Answer 2

-

Is it really happening because of x-www-form-urlencoded? If so, why then we are able to get 200 Ok with [email protected] and any other real email?

it seems that it's a bug with the way the url encoded data is being decoded in your test product. For example consider the below comment https://github.com/angular/angular/issues/18261#issuecomment-331050300

Here , + sign in url encoded values are being replaced .

I think something similar is happening in test product where numbers are not decoded as expected.

The server should handle both content type the same way.

https://dev.to/getd/x-www-form-urlencoded-or-form-data-explained-in-2-mins-5hk6

Maybe we should look at some Headers or other additional information and if yes - where exactly?

About headers and content type , you should ask for the API contract . Which is just a documentation stating what all headers, what body, what methods a API endpoint supports and what response it gives for different scenarios.

Usually a swagger page is setup for this purpose instead of paper documentation

I can't even google anything because I don't know exactly what to find. I googled articles about form-data/x-www-form-urlencoded, HTTP (https://developer.mozilla.org/en-US/docs/Web/HTTP) and still can't localize the bug.

Try different boundary value, and partition scenarios like character length , numbers , special characters , different encodings , etc

Eg: try giving exact char plus a digit , if error comes then just give digit . Then we can confirm that the error is due to the wrong decoding of number by the system

Answer 3

It might be variety of things.

Return message only shows in payload internal server error so you need to check internally, on the server what happened. 80% of this type of bugs is something in DB (bad constraints on the tables).

Then only way to know for sure is to see what backend is doing and without code or access to proper logs it's impossible.