[danShumway]

I understand being upset about the tracking aspect, but attaching query params to a link isn't breaking anything. Of all the ways Facebook could have implemented something like this, I actually prefer it this way. Query params are easy for me and other adblockers to strip off. Imagine if they were messing with request headers or something that was harder to notice or change.

An incredibly small number of sites might already be using `fbclid` internally, and an even smaller number won't be able to update their sites.

I am totally on board the don't-break-the-web train, but this just doesn't seem like a problem to me. Maybe once stats come out we'll see that it's a bigger issue, but... I kinda doubt it.

[patrickyeon]

I got caught this weekend where I linked an image on Facebook, and it generated the preview properly but the link is broken because the host 404's with the added fbclid parameter.

I entered: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg

Facebook made: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg?fbclid=IwAR2...

So sure, there may be an argument that the server should ignore that param. But it's absolutely false to say it "isn't breaking anything".

[kiallmacinnes]

I guess this makes sense. The request contained something the server didn't understand, and wasn't expecting, so returning a 404 seems sane.

After all, as a developer, it's my site - I choose the URLs (including the query strings) which are valid and acceptable to me.

I wonder how many sites other than Twitter are rejecting requests with unknown query parameters?

[danShumway]

Huh. That is very surprising to me, but I stand very corrected.

I would consider it to be pretty bad practice to treat query params this way, extra query params should be ignored. However, web standards are descriptive, not prescriptive. If enough sites have strict requirements about the number of query params, then it doesn't really matter what good practice is, and Facebook should accommodate this by moving back to cookies or at least make it opt-in or something.

[lolc]

Facebook can't set arbitrary request headers easily. That would require messing with how the user-agent retrieves things. Cookies are the chosen way servers can set client request headers. So the tracking-information is passed by a cookie. Now since browsers are starting to be selective about cookies, Facebook becomes inventive.

Adding a request parameter absolutely will break things. And they knew this. The only question was what's worse: Not being able to track some people or breaking some of their links. Facebook decided the former is more important to them and their customers.

And even if nothing else brakes, uglifying the URL people are posting is in itself an anti-feature.

[danShumway]

I'm less worried about uglifying URLs, and more about the 404 stuff that a few other people have posted about now. It never occurred to me that there'd be more than an extremely minimal number of sites that would error out when receiving extra query params.

That's a new one for me, I need to make sure I remember it in the future. From what I'm seeing online, it's not even necessarily considered bad practice, so... I dunno anymore.

But agreed, Facebook should back this out.

[lolc]

Try going to a Pizzeria and say "Pizza Margherita, with extra Zejeako please". Should they just give you a Pizza Margherita because they don't know what Zejeako is? Or should they tell you they can't do it?

> Facebook should back this out.

They won't. They knew what would happen and did it anyway.