Inconsistency in Request constructor when rewriting a used body

[harrishancock]

Script authors sometimes have a need to rewrite a Request's body, e.g. a service worker that transforms POST messages. There is currently no easy way to do this if the original body must first be read. Currently, the following code will throw:

let request = new Request("https://example.com/", {
  method: "POST",
  body: "an old body"
})

// Disturb the request's body.
let body = await request.text()

// Throws in Request ctor, step 7
let newRequest = new Request(request, {
  body: "a new body"
})

The last line throws, because Request's constructor is supposed to check that its first parameter is not disturbed (step 7) before it checks if its initialization dictionary contains a body property that will override the old body (steps 38-44).

This seems like a bug in the spec, because if we were to comment out the await request.text() line, the code snippet would work as intended: newRequest would have "a new body" as its body. That tells me that the intent was probably to allow authors to concisely rewrite bodies in just this way.

Note that even if step 7's check were modified or moved after the body extraction steps, there remains some ambiguity: if Request()'s first parameter is another Request object, step 43 unconditionally creates a new ReadableStream object from the old request's body, which I would expect to throw if the body were disturbed. Perhaps #463 will resolve that ambiguity.

/cc @kentonv

[annevk]

It does seem reasonable to make this work, indeed.

cc @yutakahirano

[yutakahirano]

We can do that, but I think #463 is not related.

[harrishancock]

Great! In that case, I suppose one possible fix would be as simple as changing Request's constructor's step 7.1 from:

If input is disturbed or locked, then throw a TypeError.

to:

If input is disturbed or locked and init's body member is not present, then throw a TypeError.

If that's acceptable, I can prepare a PR. I guess there's not really any way to write a WPT test for this change, since I'm unaware of any browser implementation of request.body?

[yutakahirano]

That is not enough as in the first comment. Changing step 43 to

inputBody is non-null and inputBody is body, ...

will solve the issue.

[annevk]

@wanderview do you know if we have an implementation of request.body behind a flag in Firefox? Or if there are tests for that feature somewhere?

[wanderview]

We don't have any request.body implementation yet.

[youennf]

Safari Tech Preview probably has request.body

[harrishancock]

@youennf good call. I don't have a Mac handy, but I downloaded Epiphany Tech Preview on Linux, which (I think?) uses the same WebKit that Safari does. It indeed has request.body. And indeed, it exhibits the throwy behavior I described in this issue.

In that case, I can explore writing a WPT test for this.

Also, I have a PR up for this at #675 -- I'm working on getting participant approval on my end.

[youennf]

Nice to see Epiphany TechPreview in action :)

[mcatanzaro]

(Interrupting this fetch discussion for a tangent:

I don't have a Mac handy, but I downloaded Epiphany Tech Preview on Linux, which (I think?) uses the same WebKit that Safari does.

Ah! It's new, we don't have any telemetry, and you're the first person I've heard of to use it, besides me. That's cool. Congrats.

A bunch of code is platform-specific and WebKit on Linux has more bugs than macOS does, but yes, it's upstream WebKit, not a fork or anything. Currently it's based on a stable branch that branched off of WebKit trunk about three weeks ago, in preparation for a new stable release series. In about a month or so, we'll switch back to using snapshots of trunk.

And we just made a huge experimental UI change to Epiphany's address bar two days ago... it's not quite finished, so overlook that please. ;)

Sorry for the tangent!)

[harrishancock]

Thanks for the info @mcatanzaro! It was in fact your blog post that led me to try it out. It's great to have one more implementation to test against on Linux.