Hacker News new | ask | show | jobs
by vntok 2795 days ago
My guesstimate is that the number of URLs that are shared on Facebook AND that already have a completely orthogonal "fbclid" parameter is infinitesimal.

Maybe among the URLs shared on Facebook there are a few whose servers only respond to a fixed amount of parameters, changing their behaviour when additional unused parameters are appended to the query string, but I imagine that the number of such cases is so low it's not even worth considering.

What exactly is Facebook breaking, in your opinion?

Would Facebook also break things if they were instead making an async request to the destination and appending a custom header to it, something like "X-Coming-From-Facebook"?

3 comments

It breaks some server-side caches. And the article itself notes that pages were indexed by Google with the "fbclid" parameter attached.

I don't get the part about async requests. What's the scenario?

> What exactly is Facebook breaking, in your opinion? > > Would Facebook also break things if they were instead making an async request to the destination and appending a custom header to it, something like "X-Coming-From-Facebook"?

Extra headers are typically ignored, not only since different clients send different headers since the beginning.

I know multiple systems which however decode the query string and complain about unknown options or don't accept a query string at all for some resources. On the later case it is ignorance on the other case it is intensive input validation.

This is the reason why Google Analytics can be configured to read marketing parameters out of the hash fragment instead of the query string. A surprising number of sites will choke when unexpected data shows up in either the query string or the hash fragment, but very few will choke on both (most sites that mishandle query parameters are from an era before rich use of fragments became common).

Notably, most links with GA marketing parameters are under the control of the website owner. Facebook links are not. This makes such a work-around less feasible.

I've seen a broken link from this url parameter already.