Reputation: 24129
The url for this gif of Michael Jackson eating Tide Pods has some interesting behavior I haven't seen before. I'm an avid internet user but my knowledge of HTTP is limited. I know that a webserver can respond however it wants to a request and provide metadata to help a browser figure out what sort of content it actually responded with, so it's not too surprising that a .gif
url could actually return a something other than a .gif
and be correctly displayed. What confuses me is how the webpage generated by the .gif
url contains itself in an img
tag.
Is this just some sort of opaque server-side magic? (i.e. server is using HTTP request header to guess if the request is coming from a URL in a <img>
or a browser address bar)
Upvotes: 3
Views: 105
Reputation: 10899
In this case, what seems to make a difference is the presence of text/html
in accept:
header.
Try:
curl 'https://media1.tenor.com/images/f1fec382c29ce096bfbacd7844c54e0f/tenor.gif' \
-H 'accept: text/html'
then try:
curl 'https://media1.tenor.com/images/f1fec382c29ce096bfbacd7844c54e0f/tenor.gif' \
-H 'accept: */*'
When requesting an image, like through an HTML
<img>
element, user-agent often sets a specific list of media types to be welcomed:
|User Agent|Value |
-----------------------------------------
|Firefox |*/* (since Firefox 47) |
|Safari |*/* |
|Chrome |image/webp,image/*,*/*;q=0.8|
Upvotes: 3