Skip body processing

[plehegar]

[[

User agents MUST honor the HTTP headers (including, in particular, redirects and HTTP cookie headers),

This seems to be new in this version of the spec and I don't understand the reasoning behind it. Why MUST user agents honor all response headers? If (as I believe most user agents do) a user agent typically ignores Set-Cookie headers from different origins, is that user agent non-conformant with Beacon? This requirement seems unlikely to be followed, as it would introduce privacy risks. ]] https://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0109.html from @npdoty

See also http://www.w3.org/2014/10/28-webperf-irc and http://www.w3.org/2015/10/webperf-tpac2015-minutes#item204

[igrigorik]

This is a continuation of last point in https://github.com/w3c/beacon/pull/19#discussion_r46188014.

@annevk can we add an extra flag/step in https://fetch.spec.whatwg.org/#dom-global-fetch to skip response body processing? For Beacon we want process headers, but the response body -- if one is present -- should just be flushed to /dev/null :)

[annevk]

dom-global-fetch is the method, not the algorithm sendBeacon() invokes.

In any event, we could add something explicit, but what observable side effect do you think there is if the user agent doesn't ignore it? I don't think we need to specify optimizations normatively.

@plehegar actually cookies are typically processed cross-origin.

[igrigorik]

@annevk on the client side we buffer and retain a reference to the body, even though nobody will ever consume it (seems unnecessary). A malicious server could stream some large file and consume user's bandwidth, with no visible callbacks/etc? In fact, now that I think about it, we should probably close the request (e.g. RST_STREAM with h2) if we get a non-empty body in response to sendBeacon?

[annevk]

It still doesn't seem observable to the page though. Observable to the server perhaps, but that matters less.

[igrigorik]

@annevk right, neither the initiator page or the user can observe the response, which means a malicious server could stream a large response and consume client's resources + user's data. We should protect ourselves (and the user) here and abort the request if body is not empty.

[annevk]

Sure, but that does not need to be normative. OOM is something to always be aware of.

[igrigorik]

Fair enough. Stepping back, the intent here was to indicate that the response body is a no-op and that it is reasonable for the UA to drop it on the floor + reset the response stream if it sees any body to avoid incurring any extra data transfers.

I can move this into a non-normative note. Would that work? /cc @toddreifsteck

[toddreifsteck]

I believe it works for the Beacon spec. Ideally, I think the Fetch abstraction should support the concept of not returning the body but the Beacon spec will be fine if the Fetch spec does not add this concept.

[annevk]

@toddreifsteck stepping back too, I guess I'd be okay considering a new primitive of sorts that we might even be able to expose to script at some point, if it's something user agents can reliably implement. That is, make a request, get the response headers, and ignore any body, perhaps even close the connection. @mnot, what do you think?

If that is something we want in general, please file an issue against Fetch.

[igrigorik]

Moved to a non-normative note in: https://github.com/w3c/beacon/commit/daf6bd0fa72cc71ffd9cd830c90d97a0c4fc3818. How does that look?

[mnot]

Er, HEAD? 204 status code?

[igrigorik]

@mnot yeah, 204 is the best practice for well-behaved servers. The concern here is enforcing from the client-side for servers that don't follow that.. That is, the client does not expect a body and if one is provided we want to (maybe?) ~error out the stream.

[igrigorik]

For fossil record.. Should be resolved via #23.