Don't use browser Request api, make our own simple one

[JoelEinbinder]

@aslushnikov can you fill in why? I just have it in my notes that we should do it.

[Garbee]

What exactly would this kind of API look like? I think not using the built in browser systems where available is harmful. As then developers need to learn yet-another-syntax to get the same results. Even though we already have (and are probably using) exactly what they know underneath.

[aslushnikov]

What exactly would this kind of API look like?

We'll get rid of Headers object and use something like a map instead. It would be consistent with page.setHTTPHeaders methods.

I think not using the built in browser systems where available is harmful. Even though we already have (and are probably using) exactly what they know underneath.

The API in question is consumed by node.js, not by browser. We don't have fetch api in node. We have protocol's network domain which we expose via the puppeteer's request and puppeteer's response classes.

Browser also has Request and Response classes, so we tried to align puppeteer's request and response with the browser counterparts. It turned out that:

• our capabilities are very limited, for example, puppeteer's request implements only 3 our of 11 fields of the browser's request.
• our usage scenario differs from the browser's one, so we'd like to have a slightly different api, for example Request.response() method

Since we failed to implement browser api to a reasonable extend, we don't want to commit to it any more.

[Garbee]

Ah, thanks for the clarification @aslushnikov. Knowing that it SGTM to make this change.