You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import {
test,
expect
} from '@playwright/test';
test('upload file', async({
page
}) => {
// When POSTing to this url, get response from test.har
await page.context().routeFromHAR('test.har', {
url: 'https://httpbin.org/post',
update: false,
updateContent: 'embed'
});
// Run the test (upload a file and click submit)
await page.goto('http://localhost:80/');
const [fileChooser] = await Promise.all([
page.waitForEvent('filechooser'),
page.locator('#file').click()
]);
await fileChooser.setFiles('sample.txt');
await page.locator('button').click();
// If the response is served from the test.har file,
// we should get a "success" response.
await expect(page.locator('#status')).toContainText('success');
});
Put sample.txt and test.har in the top-level directory
<html>
<body>
<div class="container">
<h1>Multipart File Upload</h1>
<form id="form" enctype="multipart/form-data">
<div class="input-group">
<label for="files">Select files</label>
<input id="file" type="file" multiple />
</div>
<button class="submit-btn" type="submit">Upload</button>
</form>
<div id="status"></div>
</div>
<script type="text/javascript">
const form = document.querySelector('form');
form.addEventListener('submit', async(event) => {
event.preventDefault();
// This is the request we would normally use. But it does not
// work when running against the test.har file, because Playwright
// will not find a match in that file -- due to the fact that the
// boundaries won't match (fetch uses random boundaries each time).
let request = new Request('https://httpbin.org/post', {
method: 'POST',
body: new FormData(form)
});
// ### BEGIN WORKAROUND
// As a clunky workaround, rebuild request using a fixed boundary
// To demonstrate the Playwright bug, commenet out this workaround
const body = new TextDecoder('utf-8').decode(await request.arrayBuffer());
const currBoundary = body.substring(2, 40);
const newBoundary = '----WebKitFormBoundary0123456789ABCDEF';
request = new Request(request, {
headers: {
'Content-Type': `multipart/form-data; boundary=${newBoundary}`,
},
body: body.replaceAll(currBoundary, newBoundary)
});
// ### END WORKAROUND
// Now make the request
const response = await fetch(request);
const json = await response.json();
document.querySelector('#status').innerHTML = JSON.stringify(json, null, 2);
});
</script>
</body>
</html>
Run the test (npx playwright test tests/example.spec.ts).
The test will fail without the "WORKAROUND" in the index.html that hardcodes the boundary. In other words, if we let the browser choose its own (random) boundary -- which is the normal case -- then the test will always fail when running using the test.har file
Expected behavior
I expect the test to succeed and for Playwright to use the contents of the HAR file.
Actual behavior
The test fails because no match is found in the HAR file. It appears that the match is not found because of the Boundary mismatch in the multi part form data.
Additional context
I think Playwright should ignore the fact that the Boundary is different each time. When looking for a match in the HAR file, it should not consider the actual Boundary value.
Version
1.45.0
Steps to reproduce
The test will fail without the "WORKAROUND" in the index.html that hardcodes the boundary. In other words, if we let the browser choose its own (random) boundary -- which is the normal case -- then the test will always fail when running using the test.har file
Expected behavior
I expect the test to succeed and for Playwright to use the contents of the HAR file.
Actual behavior
The test fails because no match is found in the HAR file. It appears that the match is not found because of the Boundary mismatch in the multi part form data.
Additional context
I think Playwright should ignore the fact that the Boundary is different each time. When looking for a match in the HAR file, it should not consider the actual Boundary value.
Environment
The text was updated successfully, but these errors were encountered: