feat(develop): Add page context
#13203
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
| `user_agent` | ||
|
|
||
| : _Optional_. The user agent of the page that the event occurred on. | ||
|
|
||
| - Example: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36` |
There was a problem hiding this comment.
How can a "page" have a user agent?
There was a problem hiding this comment.
hmm, how do we phrase this? We need to send the user agent somehow, as the server infers the os/browser stuff from it 🤔
We could make it page_request, would that make more sense?
There was a problem hiding this comment.
After thinking about this, I think it makes more sense to split this out into #13205
|
Overall not a big fan. A page does not exist on mobile, and the naming could be better. |
An |
|
Well, you wrote client SDKs. If this is just for Web FE, it's a different story. |
|
|
||
| Page context contains information about the page that the event occurred on. | ||
|
|
||
| `full.url` |
There was a problem hiding this comment.
It feels a bit overkill for me to store everything in separate fields. What's wrong with just having a url field?
There was a problem hiding this comment.
cc @cleptric had concerns about pii stripping etc!
There was a problem hiding this comment.
getsentry/sentry-javascript#7667 for context. We imo should not emit the full URL.
There was a problem hiding this comment.
I updated this to be: url, http.query and http.fragment.
|
Generally I am strongly in favor of this because request contexts make literally no sense on frontend events. |
|
If you stop sending this data, this will eventually break everything that is built ontop of the existing fields, metric extraction rules for the performance products, existing filters, alerts, dashboards users built etc. I would recommend heavily analyzing what needs to be done for the entire stack before committing to just moving data around, just because the naming may not be 'optimal' for a frontend SDK. |
The naming is not just not optimal, it is simply wrong. there are not really any headers, the http method is meaningless, nobody thinks about this as HTTP Request information. In regards to backwards compatibility: We'll continue to send the data as As far as I can tell, neither on issues stream, nor on trace explorer, nor alerts, allow to filter by |
This adds a new context to develop docs:
The new
pagecontext should be used to add information about the current page that an event originated on. It should be used for web-based client SDKs instead of putting this information intoevent.request.Relay will need to extract data from this (if available) instead of
event.request.