6 ms·

When you paste in a URL to share it with your friends, Facebook tries to grab some information from that webpage to provide a summary.

toomuchtodo 6y ago
What happens if that link performs an action upon a GET request? Edit: Folks, I agree with you all, but I've seen a lot of garbage out there. Just asking the question for the discussion.
- vasco 6y ago
  That "link" doesn't respect the GET semantics then.
- thinkindie 6y ago
  that's your own problem because you are going against the HTTP protocol standard. GET should be idempotent.
  - thaumasiotes 6y ago
    Going against the HTTP standard isn't a problem. For example, it's a good practice to ignore HEAD requests as opposed to responding appropriately. The problem with unsafe GET is that it conflicts with reality, not that it conflicts with the standard.
    - dragonwriter 6y ago
      > Going against the HTTP standard isn't a problem. For example, it's a good practice to ignore HEAD requests as opposed to responding appropriately. That's only against the standard of you advertise HEAD as a supported method on the resource, which converts it from a good idea in some circumstances to a bad one, so if there is a good example to support your claim, that isn't it.
      - thaumasiotes 6y ago
        The most classic example is the JWT specification, which says you need to honor the encryption algorithm defined by the token you receive. (JWT includes a "none" algorithm, making token forgery trivial when the parser implements the standard.) It's known widely enough now that people have chosen to reinterpret the language of the standard in order to claim that their implementations are compliant -- after making the change specifically to bring themselves out of compliance. (It's possible that it's been so long that the standard itself has been changed to accommodate this. But regardless, the point stands that standards compliance is not a virtue for its own sake. This wasn't a good idea back when everyone agreed that the standard required it, it's not a good idea now, and future bad ideas do not in general become good ideas by virtue of being specified in standards.)
- crazygringo 6y ago
  Then like literally every search engine and website crawler ever does, the action will be performed. Which is why it's bad practice to design your website using GET for actions. That's what POST is for. I mean, using GET for actions will break so many things -- browser prefetching, link previews, the list is endless. If you use GET for actions, just... yikes.
  - dependenttypes 6y ago
    > browser prefetching, link previews Both of them are pretty bad. I do not see GET actions breaking anything that is not trash.
- WookieRushing 6y ago
  Then it performs the action, what else would it do?
- dragonwriter 6y ago
  Then the action needs to be harmless, because GET is defined as not merely idempotent but also safe. Didn't we already learn this lesson after all the unsafe-GET problems unveiled when prefetching browser accelerators came on the scene in, IIRC, the late 1990s?
  - thaumasiotes 6y ago
    > Then the action needs to be harmless to repeat, because GET is defined as idempotent. No, this is a terrible response. The action needs to be harmless to execute every time, not just every time after the first time. HTTP DELETE is conceptually idempotent, but you don't want to be deleting stuff with GET requests. That's why the standard provides a DELETE method! The distinction that really matters is safe/unsafe, not idempotent/unique. (Do you need to use DELETE for deleting stuff? No, POST is fine.)
    - dragonwriter 6y ago
      > The action needs to be harmless to execute every time, not just every time after the first time. You are correct, and the grandparent post has been updated appropriately.
    - bkanber 6y ago
      > No, this is a terrible response. As an aside, this kind of hyperbole really gets under my skin. It wasn't a terrible response. That statement is already technically correct: GET is idempotent, and the definition of idempotency is that it is harmless to repeat. Your gripe is that OP didn't mention that GET is not only idempotent but must also be "safe"; i.e. that it should not alter the resource. OP got it 50% correct. Does that omission make his comment a "terrible response"? No -- just incomplete.
      - thaumasiotes 6y ago
        Yes, it was a terrible response. Here are some examples of idempotent requests: - Change the email address registered to my account from owner@gmail.com to new_owner@136.com . - Instead of sending my direct deposit to account XXXX XXXX at Bank of America, from now on, send it to account YYYY YYYY at Wells Fargo. - Delete my account. - Drop the database. None of these have any business being available to GET requests. Objecting to a misconfigured endpoint on the grounds that the functionality it implements is not idempotent implies that the lack of idempotence is what was wrong. That's a bad thing to do - anyone who takes your lesson to heart is still going to screw themselves over, because you gave them terrible advice. They may do it more than they otherwise would have, because you gave them advice that directly endorses really bad ideas. Idempotence or the lack thereof is beside the point. Messing up on endpoint idempotence means you might hurt the feelings of a document. Messing up on endpoint safety means you might lose all your data as soon as anyone else links to your homepage. Or worse.
- claudiulodro 6y ago
  I'm not sure what sort of action you mean, but Facebook doesn't fetch the page in real-time using the client's browser. Some sort of job scrapes the page HTML looking for metadata and then uses that metadata to populate the preview. If you want to play around with what it "sees", you can test using the sharing debugger: https://developers.facebook.com/tools/debug/ https://developers.facebook.com/tools/debug/
systemvoltage 6y ago
This pattern needs to die. Whenever I paste a link in any sort of messaging app - iMessages to Slack - it puts a thumbnail and summary, polluting the entire conversation with tons of noise. Messaging apps have no business in looking up the URL. Just let it pass as a link. Fuck everything about this and we need to push back on this nonsense.
- nitrogen 6y ago
  I like link previews. I don't like when they are managed server-side instead of client-side.
  - crazygringo 6y ago
    Caching a link's title and thumbnail server-side will save your site potentially millions of requests from Facebook and elsewhere. Seems like a benefit for site owners to me. Not to mention that the server is reducing the image size of a thumbnail, potentially converting from HTTP to HTTPS, and so on.
    - lixtra 6y ago
      > Seems like a benefit for site owners to me. Maybe, but it’s definitely less control for the site owner. Maybe she wants to do analytics on the previews (how far shared, which ip regions) or delete the content at a specific time. Etc.
  - elviswolcott 6y ago
    The issue with doing them client side (other than the missed cache opportunity of using a server) is that it means you're having every user in the chat send a request to an arbitrary URL from their device. Also CORS makes this impossible 99% of the time.
    - ekimekim 6y ago
      The third approach, which Signal uses as a privacy preservation measure, is for the sender to generate the link preview on send. Of course, this then opens up abuse where the sender can arbitrarily control the "link preview" to say whatever they want.
slig 6y ago
And to prevent some URLs to be posted.

toomuchtodo 6y ago

What happens if that link performs an action upon a GET request? Edit: Folks, I agree with you all, but I've seen a lot of garbage out there. Just asking the question for the discussion.

vasco 6y ago
That "link" doesn't respect the GET semantics then.
thinkindie 6y ago
that's your own problem because you are going against the HTTP protocol standard. GET should be idempotent.
- thaumasiotes 6y ago
  Going against the HTTP standard isn't a problem. For example, it's a good practice to ignore HEAD requests as opposed to responding appropriately. The problem with unsafe GET is that it conflicts with reality, not that it conflicts with the standard.
  - dragonwriter 6y ago
    > Going against the HTTP standard isn't a problem. For example, it's a good practice to ignore HEAD requests as opposed to responding appropriately. That's only against the standard of you advertise HEAD as a supported method on the resource, which converts it from a good idea in some circumstances to a bad one, so if there is a good example to support your claim, that isn't it.
    - thaumasiotes 6y ago
      The most classic example is the JWT specification, which says you need to honor the encryption algorithm defined by the token you receive. (JWT includes a "none" algorithm, making token forgery trivial when the parser implements the standard.) It's known widely enough now that people have chosen to reinterpret the language of the standard in order to claim that their implementations are compliant -- after making the change specifically to bring themselves out of compliance. (It's possible that it's been so long that the standard itself has been changed to accommodate this. But regardless, the point stands that standards compliance is not a virtue for its own sake. This wasn't a good idea back when everyone agreed that the standard required it, it's not a good idea now, and future bad ideas do not in general become good ideas by virtue of being specified in standards.)
crazygringo 6y ago
Then like literally every search engine and website crawler ever does, the action will be performed. Which is why it's bad practice to design your website using GET for actions. That's what POST is for. I mean, using GET for actions will break so many things -- browser prefetching, link previews, the list is endless. If you use GET for actions, just... yikes.
- dependenttypes 6y ago
  > browser prefetching, link previews Both of them are pretty bad. I do not see GET actions breaking anything that is not trash.
WookieRushing 6y ago
Then it performs the action, what else would it do?
dragonwriter 6y ago
Then the action needs to be harmless, because GET is defined as not merely idempotent but also safe. Didn't we already learn this lesson after all the unsafe-GET problems unveiled when prefetching browser accelerators came on the scene in, IIRC, the late 1990s?
- thaumasiotes 6y ago
  > Then the action needs to be harmless to repeat, because GET is defined as idempotent. No, this is a terrible response. The action needs to be harmless to execute every time, not just every time after the first time. HTTP DELETE is conceptually idempotent, but you don't want to be deleting stuff with GET requests. That's why the standard provides a DELETE method! The distinction that really matters is safe/unsafe, not idempotent/unique. (Do you need to use DELETE for deleting stuff? No, POST is fine.)
  - dragonwriter 6y ago
    > The action needs to be harmless to execute every time, not just every time after the first time. You are correct, and the grandparent post has been updated appropriately.
  - bkanber 6y ago
    > No, this is a terrible response. As an aside, this kind of hyperbole really gets under my skin. It wasn't a terrible response. That statement is already technically correct: GET is idempotent, and the definition of idempotency is that it is harmless to repeat. Your gripe is that OP didn't mention that GET is not only idempotent but must also be "safe"; i.e. that it should not alter the resource. OP got it 50% correct. Does that omission make his comment a "terrible response"? No -- just incomplete.
    - thaumasiotes 6y ago
      Yes, it was a terrible response. Here are some examples of idempotent requests: - Change the email address registered to my account from owner@gmail.com to new_owner@136.com . - Instead of sending my direct deposit to account XXXX XXXX at Bank of America, from now on, send it to account YYYY YYYY at Wells Fargo. - Delete my account. - Drop the database. None of these have any business being available to GET requests. Objecting to a misconfigured endpoint on the grounds that the functionality it implements is not idempotent implies that the lack of idempotence is what was wrong. That's a bad thing to do - anyone who takes your lesson to heart is still going to screw themselves over, because you gave them terrible advice. They may do it more than they otherwise would have, because you gave them advice that directly endorses really bad ideas. Idempotence or the lack thereof is beside the point. Messing up on endpoint idempotence means you might hurt the feelings of a document. Messing up on endpoint safety means you might lose all your data as soon as anyone else links to your homepage. Or worse.
claudiulodro 6y ago
I'm not sure what sort of action you mean, but Facebook doesn't fetch the page in real-time using the client's browser. Some sort of job scrapes the page HTML looking for metadata and then uses that metadata to populate the preview. If you want to play around with what it "sees", you can test using the sharing debugger: https://developers.facebook.com/tools/debug/ https://developers.facebook.com/tools/debug/

systemvoltage 6y ago

This pattern needs to die. Whenever I paste a link in any sort of messaging app - iMessages to Slack - it puts a thumbnail and summary, polluting the entire conversation with tons of noise. Messaging apps have no business in looking up the URL. Just let it pass as a link. Fuck everything about this and we need to push back on this nonsense.

nitrogen 6y ago
I like link previews. I don't like when they are managed server-side instead of client-side.
- crazygringo 6y ago
  Caching a link's title and thumbnail server-side will save your site potentially millions of requests from Facebook and elsewhere. Seems like a benefit for site owners to me. Not to mention that the server is reducing the image size of a thumbnail, potentially converting from HTTP to HTTPS, and so on.
  - lixtra 6y ago
    > Seems like a benefit for site owners to me. Maybe, but it’s definitely less control for the site owner. Maybe she wants to do analytics on the previews (how far shared, which ip regions) or delete the content at a specific time. Etc.
- elviswolcott 6y ago
  The issue with doing them client side (other than the missed cache opportunity of using a server) is that it means you're having every user in the chat send a request to an arbitrary URL from their device. Also CORS makes this impossible 99% of the time.
  - ekimekim 6y ago
    The third approach, which Signal uses as a privacy preservation measure, is for the sender to generate the link preview on send. Of course, this then opens up abuse where the sender can arbitrarily control the "link preview" to say whatever they want.

slig 6y ago

And to prevent some URLs to be posted.