Implement Request.clone#92
Conversation
It already is infallible internally, so might as well reflect that in the signature and clean up the callsites.
I stumbled upon this while implementing `Request.clone`, and while this change doesn't cause any additional WPT tests to pass, I'm certain that it's required: otherwise, `new Request(incomingRequest)` will not apply `incomingRequest`'s header entries to the new request if `.headers` has never been read on `incomingRequest`.
guybedford
left a comment
There was a problem hiding this comment.
Looks great. Since there isn't WPT coverage for this, can we add an integration test? For example, porting the cases from https://github.com/fastly/js-compute-runtime/blob/main/integration-tests/js-compute/fixtures/app/src/request-clone.js.
Perhaps we need to update wpt? |
|
@JakeChampion we are on a recent WPT, we just don't run |
|
@tschneidereit if it helps, I added a simple clone test here, which is giving an error just on this line: with the stdout when that line is enabled (from tests/integration/fetch/stderr.log) reading: |
015c6c6 to
0c775f0
Compare
|
I went ahead and pushed up a fix for the headers cloning bug, will land this later today. |
|
Thank you for doing that! <3 Can you say what the fix actually was? That commit for me renders with lots of changes that seem to only change whitespace (even if I set the "ignore whitespace changes" flag) so it's hard to tell what actually changed |
|
Oh, never mind: clicking on the commit in the email notification showed something entirely different from what I get when viewing only this commit in the PR itself 🤷🏻 |
|
Yes, I applied clang format by mistake, then pushed up the correction. |
|
Ah, that makes sense! As does the fix :) |
This is fairly straightforward by itself. I threw in a couple of additional commits that clean a few things up. They come with detailed commit messages describing what they're about. Let me know if you'd prefer splitting them off, though.
Fixes #84