Comments (14)
After asking around, I think this would be a most welcome addition, and is likely to help adoption.
from beacon.
@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.
from beacon.
A request has an associated keepalive flag...This can be used to allow the request to outlive the environment settings object, e.g., navigator.sendBeacon and the HTML img element set this flag
I'm surprised to see
img
mentioned there, nor do I see any plumbing in HTML spec for keepalive on images.. Surprised because I would not expect the UA to allow an image request to continue as the page unloads, whereas the whole point of sendBeacon and keepalive flag is to allow the request outlive the navigation context. @yoavweiss are you familiar with this particular corner of the Fetch+HTML image processing specs?
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?
from beacon.
Based on first-hand experience with a few large(r) clients, I do think it might be a reasonable addition:
- Some services rely on processing pipelines that analyze requests logs only, and all the data they need is encoded directly in the URL itself (i.e. there are no payloads). I know a few services that have since allowed POST for such use cases as well, but they don't send a payload and still rely on encoding data in the URL's. These are not impossible hurdles, but they are unnecessary hurdles that have hurt adoption.
- Some services invoke redirect chains, because they need the same beacon to be registered against multiple backends... And POST + 3xx is funny business. The UA converts POST to GET and the payload is dropped. This is correct behavior, but it's a gotcha for many. As such, technically we're already and unintentionally doing GET's in some cases..
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.
from beacon.
And POST + 3xx is funny business. The UA converts POST to GET and the payload is dropped
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.
from beacon.
Indeed, 307 and 308 preserve the method and payload. Also, if you did do GET, you cannot have a payload.
from beacon.
There is some interest in GET beacon support for AMP analytics as well: ampproject/amphtml#2446 (comment)
from beacon.
I think I'm starting to lean somewhat in favor of trying to define sendBeacon()
in terms of fetch()
as @sicking mentions above. Keeping them around as too distinct primitives is just going to be confusing in the long run.
from beacon.
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.
from beacon.
Closing.. Solved via #27 + whatwg/fetch#388 (comment).
from beacon.
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.
from beacon.
A request has an associated keepalive flag...This can be used to allow the request to outlive the environment settings object, e.g., navigator.sendBeacon and the HTML img element set this flag
I'm surprised to see img
mentioned there, nor do I see any plumbing in HTML spec for keepalive on images.. Surprised because I would not expect the UA to allow an image request to continue as the page unloads, whereas the whole point of sendBeacon and keepalive flag is to allow the request outlive the navigation context. @yoavweiss are you familiar with this particular corner of the Fetch+HTML image processing specs?
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.
from beacon.
See whatwg/html#1655 and links from there.
from beacon.
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.
Well, turns out the note is partially correct. Images are kept alive, but only when set inside page dismissal events.
from beacon.
Related Issues (20)
- How important is it for sendBeacon() to follow redirects? HOT 12
- Remove referrer source definition + HTML5.2 dep HOT 2
- corsMode calculation in the "Processing Model" section is broken HOT 1
- Typo in Introduction note
- Typo in Processing Model - fetch step HOT 1
- Typo in Privacy and Security HOT 1
- Resource Timing + beacon test HOT 2
- beacon-navigate is broken HOT 1
- Firefox, Chrome and Edge all fail http referrer test HOT 5
- Typo in Example 1 code HOT 5
- navegator.sendBeacon cookie visibility question. HOT 4
- When can Beacon support the GET method? HOT 2
- Drop dependencies section HOT 1
- Integrate with Resource Timing
- Option to request beacon be compressed HOT 9
- Account for fetch algorithm rename
- Setup auto publishing HOT 9
- References terms from Page Visibility, which is a discontinued draft HOT 2
- Is "entry setings object" correct? HOT 1
- Duplicate, vague, and monkeypatching normative requirements
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from beacon.