Okay, so, I've boiled down this issue as much as I can. I've reduced this to as few moving parts as possible to try and identify the problem, and I still don't really understand what's happening.
I'm using the APIRequest attached to a browser context/page to simulate a JavaScript ajax call but I'm getting different results.
rq = page.request
page.evaluate(f"testFormData = '{json.dumps(post)}'")
page.evaluate(f"headers => testHeaders = headers", headers)
page.evaluate("""
$.ajax({
url: "/Patient/QuickIntake",
type: "POST",
contentType: "application/json",
headers: testHeaders,
data: testFormData,
success: function (data) {
// Returns status code 200
}
});
""")
print("JS Executed")
resp = rq.post("/Patient/QuickIntake", data=post, headers=headers) #returns status code 500
Using the exact same headers, the exact same data. According to the documentation, using data instead of form in .post assigns content type to application/json. I'm feeding the same values into the page from python as I'm using in the api call, so it shouldn't be outside javascript interfering. I can't find a way to trace/view the outgoing api call's specific headers so I can't compare side by side (if you know a way to do this without something like wireshark that'd be amazing), but the two are using the same cookies, the same headers, the same endpoint, the same browser/ip address/user data, and the same input data, and yet the server is consistently treating the rq.post call as if one of the defined headers doesn't exist.
If someone could point out whatever obivous mistake I'm making, or point me in the direction of some debugging that would help, I'd be very grateful.
This thread is trying to answer question "Why is the server treating the rq.post call differently from the APIRequest attached to a browser context/page, despite using the same headers, data, and endpoint?"
Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].