Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Intercepted requests won't return with some status codes #4454

Closed
angrykoala opened this issue May 20, 2019 · 3 comments · Fixed by #4566
Closed

Intercepted requests won't return with some status codes #4454

angrykoala opened this issue May 20, 2019 · 3 comments · Fixed by #4566

Comments

@angrykoala
Copy link

In Puppeteer 1.16.0 and 1.15.0, trying to make a fake response with the interceptor will not behave properly with some status codes (e.g. 422)

Steps to reproduce

Tell us about your environment:

  • Puppeteer version: 1.16.0
  • Platform / OS version: Linux
  • URLs (if applicable):
  • Node.js version: 10.15.3

What steps will reproduce the problem?

Having the following webpage being served at http://localhost:3000/requests.html:

<html>

<body>
    <button class="btn" onclick="doRequest()">click me</button>
    <script>
        function doRequest() {
            fetch("/api").then((res) => {
                console.log("AFTER REQUEST", res.status)
            }).catch((err)=>{
                console.log("ERR",err)
            })
        }
    </script>
</body>
</html>

And the following code with puppeteer:

const puppeteer=require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setRequestInterception(true);
  page.on("console", (log)=>{
    console.log(log.text());
  });

  page.on('request', interceptedRequest => {
      console.log(interceptedRequest.url());
      if(interceptedRequest.url().endsWith('/api')){
          interceptedRequest.respond({
              status: 422,
              body: "FAKE"
          })
      } else interceptedRequest.continue();
    });
  await page.goto('http://localhost:3000/requests.html');
  await page.waitFor(".btn");
  await page.click(".btn")
  setTimeout(()=>{
      browser.close();

  },300);
})();

What is the expected result?

The following log should appear

http://localhost:3000/requests.html
http://localhost:3000/api
Failed to load resource: the server responded with a status of 422 (Unprocessable Entity)
AFTER REQUEST 422

(behaves as expected with Puppeteer 1.14.0)

What happens instead?

The request is never completed:

http://localhost:3000/requests.html
http://localhost:3000/api

If changing the status code to 400 the request behaves as expected:

http://localhost:3000/requests.html
http://localhost:3000/api
Failed to load resource: the server responded with a status of 400 (Bad Request)
AFTER REQUEST 400

This appear to be happening with status codes from 421 to 451

The same behavior seems to be happening with non-valid status codes (e.g. 309). All this cases are working as expected on 1.14.0
@angrykoala angrykoala mentioned this issue May 20, 2019
Closed
aslushnikov added a commit to aslushnikov/puppeteer that referenced this issue Jun 10, 2019
@aslushnikov
feat(network): allow fulfilling requests with custom status text
28ed4ff 
Teach `request.respond()` to accept custom status text. It is necessary
when responding with non-standard HTTP status codes.

Fix puppeteer#4454
@aslushnikov aslushnikov mentioned this issue Jun 10, 2019
Closed
@aslushnikov
Copy link
Contributor

@angrykoala sorry for this regression. This happens because we don't have default status codes for non-standard HTTP status codes.

When #4554 lands, you'll be able specify both status and statusText, and things will work as expected.

interceptedRequest.respond({
  status: 422,
  statusText: 'fake',
  body: "FAKE"
})

@angrykoala
Copy link
Author

In which Puppeteer version is this expected to be released?

@aslushnikov
Copy link
Contributor

@angrykoala 1.18 - it'll be on June, 21st

aslushnikov added a commit to aslushnikov/puppeteer that referenced this issue Jun 11, 2019
@aslushnikov
fix(network): allow fulfilling requests with status code 422
4ff58ac 
Migration onto fetch domain (2265974)
changed the way we generate status texts: instead of relying on build-in
list of statuses, we tried to rely upon the [Chromium implementation](https://cs.chromium.org/chromium/src/net/http/http_status_code_list.h?sq=package:chromium&g=0)

Puppeteer's list is much more exhaustive - let's keep it.

Fix puppeteer#4454
@aslushnikov aslushnikov mentioned this issue Jun 11, 2019
Merged
aslushnikov added a commit that referenced this issue Jun 11, 2019
@aslushnikov
fix(network): allow fulfilling requests with status code 422 (#4566)
8df0b3e 
Migration onto fetch domain (2265974)
changed the way we generate status texts: instead of relying on build-in
list of statuses, we tried to rely upon the [Chromium implementation](https://cs.chromium.org/chromium/src/net/http/http_status_code_list.h?sq=package:chromium&g=0).

Puppeteer's list is much more exhaustive - let's keep it.

Fix #4454
@snyk-bot snyk-bot mentioned this issue Dec 4, 2019
Open
This was referenced Feb 3, 2020
Open
Open
This was referenced Feb 22, 2020
Open
Open
@snyk-bot snyk-bot mentioned this issue Mar 10, 2020
Open
@snyk-bot snyk-bot mentioned this issue Mar 31, 2020
Open
@snyk-bot snyk-bot mentioned this issue Apr 13, 2020
Merged
@snyk-bot snyk-bot mentioned this issue May 5, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@aslushnikov @angrykoala