Should setData(data) only support POST request

[mingyc]

setData(data): Set the current beacon data. The data argument would take the same types as the sendBeacon method’s data parameter. That is, one of ArrayBuffer, ArrayBufferView, Blob, string, FormData, or URLSearchParams.

The current proposal doesn't differentiate between GET/POST for the beacon data. But most of them just don't make sense for GET request in term of url encoding, e.g. Blob, ArrayBuffer, ArrayBufferView, and FormData can contain arbitrary bytes which is difficult to encode in url.

Would it make sense to specify beacon data from setData(data) only works for POST?

[yutakahirano]

+1. Setting data to GET requests sounds strange to me. Ignoring setData calls or even throwing when the method is GET makes sense to me.

[fergald]

@yutakahirano You're suggesting that for a GET beacon, you would set the URL only and if you want to update the beacon you don't call setData, you create a new beacon with a new URL? Or maybe the URL is updateable on GET beacon but there is no setData.

[mingyc]

There was another discussion about atomic property updating in #8 where we decided to make url immutable. We might want to add a new method for updating url for GET beacon?

[fergald]

Yeah, so actually we might want to have 2 different beacons then, one for GET which can update URL and has no setData.

[yutakahirano]

Encoding arbitrary data into a URL query is not at all trivial, so I think setData is not the right interface for setting URL query. Moreover, if setData can be used to set the URL query for a GET beacon, why can't we do that for a POST beacon?

Hence I think it's good to have a separate function for setting the request content and setting the request URL query (if necessary - is there a use case for this?). For example:

• setData(data): Set data to the beacon request content. This throws if the method is "GET" or "HEAD".
• setQuery(params): Set params to the request URL query. params is a URLSearchParams.

[jdfreder]

One particularly nice thing about @fergald's suggestion is that the API is explicit, as opposed to restricting calls based on runtime configuration (HTTP method) which is a potential landmine (runtime Error) for anyone who doesn't read the spec closely.

[fergald]

@jdfreder yes, for typescript users having 2 separate beacon classes for GET and POST turns a run-time error into a compile-time error.

@yutakahirano
I hadn't thought about HEAD as a method here. Given that the response is never made available, GET and HEAD seem identical (to the page) but I suppose someone might want us to make one or the other in the request. So I guess we should facilitate both but it seems like they would have exactly the same observable behaviour.

Allowing setUrl not just seqQuery seems more flexible and I don't see a downside.

I was rather surprised to find that there are frameworks out there that use different encodings. For example, some params in Chromium Code Search URLs are ;-separated. E.g. l, drc below

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.h;l=324;drc=af55b5b6ebe03da36d40e71bd733617291c6c9c7

I complained about it once and was told that it comes from the framework they built it on. So we cannot assume that setQuery(query: SearchURLParams) will actually be OK for everyone.