-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should sendBeacon support GET? #22
Comments
After asking around, I think this would be a most welcome addition, and is likely to help adoption. 👍 |
Based on first-hand experience with a few large(r) clients, I do think it might be a reasonable addition:
My main question and concern here would be around defining a backwards compatible API, since we already have two implementations that default to POST, and I don't think we can change the default. Exposing GET as an optional method might be an option though. |
That should only be the case for some 3xx values. IIRC a POST+307 should result in another POST. Is that not the case in Chrome? Anyhow, I don't have a strong opinion here. This is a question for http-folks. In theory a GET should never result in side effects and just return a response which means that using sendBeacon which doesn't expose the response is kind of useless. But again, I'll defer to http-folks. The only thing I'd say is that we discussed allowing fetch() to opt in to send-beacon like behavior where the request can be delayed. That might be a more generic route to go. |
Indeed, 307 and 308 preserve the method and payload. Also, if you did do GET, you cannot have a payload. |
@sicking I think the theory and the reality are at odds with each other in this scenario, unfortunately. Many analytics systems currently use GET via xhr or image URL and the query string to send telemetry to the cloud. These systems usually ignore the response. The intent of adding GET support to sendBeacon is to allow these customers to move from xhr to sendBeacon for telemetry. |
There is some interest in GET beacon support for AMP analytics as well: ampproject/amphtml#2446 (comment) |
I think I'm starting to lean somewhat in favor of trying to define |
Turns out, there is a good use case for HEAD as well... It's common for navigation clicks to be bounced through several layers of redirects (as a means of registering the click) before arriving at the actual landing page. Each redirect in this chain only knows about the next hop; each redirect is owned and managed by a separate entity - i.e. there is no end-to-end visibility. Now, imagine we want to use sendBeacon to move the redirect chain out of the navigation path: click triggers an async sendBeacon that follows the same redirect chain; browser navigates directly to the destination page. If sendBeacon is GET/POST then it will bounce through all of the redirects and then land and fetch the destination page... resulting in an unnecessary fetch of the HTML markup. One obvious solution to this is to modify the chain to avoid the final redirect, but this turns out to be pretty hard in practice and is an adoption barrier for using sendBeacon. Alternatively.. If sendBeacon allowed HEAD requests, then the request would still bounce through all the redirects and land on the destination page, but we would not fetch the HTML, which avoids the duplicate bytes. This make it deployable in existing ecosystem. |
Closing.. Solved via #27 + whatwg/fetch#388 (comment). |
Following the trail of issues and PRs a few years later, I'm looking for some clarification on the most up-to-date recommendation. Please see this StackOverflow question. |
I'm surprised to see Ideally, we should track down the WPT tests for this behavior on images. If they don't exist (which would be my bet), then I wouldn't count or rely on this. |
Your surprise is well justified. That note is not correct, and images definitely do not outlive their documents. The keepalive flag is not defined for their fetch in the HTML spec, nor in implementations as far as I know. It seems like the note was added by @annevk at this commit. @annevk - any recollection as to why this was added? |
See whatwg/html#1655 and links from there. |
Well, turns out the note is partially correct. Images are kept alive, but only when set inside page dismissal events. |
A large number of existing RUM solutions depend on GET via XHR or the image tag. To ensure that sendBeacon can be used by these existing solutions, should we update it to support GET?
I think it is possible to add without significant change to the API surface if we mimic the Fetch WebIDL.
If thoughts are positive, I'll put together a pull request. Thoughts?
The text was updated successfully, but these errors were encountered: