Closed (outdated)
Project:
oEmbed
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Feb 2015 at 21:04 UTC
Updated:
20 Oct 2025 at 09:12 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
kporras07 commentedPatch attached
Comment #2
kporras07 commentedComment #3
justindodge commentedI've noticed this behavior in the past as well while debugging oEmbed requests and responses.
Regarding your patch, it looks like this first bit:
+ if ($cache && isset($cache->data) && $cache->expire > REQUEST_TIME) {just makes sure that the cache hit isn't served if it should have already expired. This isn't the issue being reported, but it's a good catch - I've been bitten in the past by the fact Drupal's cache_get() actually gives you expired data, so checking the expiration here is totally appropriate.
The second portion:
seems like it's missing the boat to me - if $lifetime doesn't equal CACHE_PERMANENT, this condition isn't met and a different expiration value will be set - and in either case, cache_set is still called.
I'm not 100% what's in $embed when there's an empty or bad response, but it seems like the first line after checking "if ($plugin['cache']) {" should just return and do nothing if it's empty.
So like:
Whatchya think?
Comment #4
justindodge commentedHere's my version of the patch per #3
Comment #5
justindodge commentedComment #6
chasingmaxwell commentedSkipping the cache_set() causes the request to be made multiple times in a single request as this function gets called several times. But with the patch in #1, invalid responses are still being cached for too long if $lifetime does not equal CACHE_PERMANENT. So I think it's better to always set $lifetime to 1 when we get an invalid response. Here's a patch to that effect.
Comment #7
justindodge commentedI think the patch in #6 is an improvement, I've put it to use for a few sites - it's clear enough to understand so I'm going to go ahead and mark RTBC.
Comment #8
Anonymous (not verified) commentedI've started to get bitten by this, too.
I must omit kporras07's double checking of the expire time. If Drupal's cache_get is returning expired data, this is a problem for Drupal or a contrib cache handler to fix.
chasingmaxwell identifies the reason for caching a bad response: it's be a waste of resources to constantly re-check a URL that isn't valid.
Patch #6 is fine, but it's not really getting to the root problem and shuffles some moderately complex PHP conditions around.
Right now, the provider callback is returning FALSE for multiple reasons:
These possibilities should inform how the cache expiration is calculated for an invalid response, but they're all indistinguishable because the callback simply returns FALSE. Instead, callback should throw exceptions, and oembed_oembed_fetch should catch them. The exceptions should represent the part that is failing, so the cache expire time can be set more intelligently.
The oEmbed standard uses HTTP statuses (401, 404, and 500) to represent errors, so this module should do the same. But what should each status mean? I don't know yet. I have a large site that uses oEmbed extensively and has a lot of errors, too. I will start logging the responses to determine which errors should be cached and which should be retried.
Comment #9
jkellendonk commentedThis was an issue for me as well. Caching "no result" broke a page on my site randomly because other modules don't handle the empty cache well, including accessing the direct file view page. My access to Youtube's oembed is a little spotty (it may be youtube or my server, not sure), so my site would break randomly due to cache expiration being at least an hour ahead. I'm basically left in a position where I have to choose between which modules I'm modifying or working around it so I can at least still update modules.
I added a script that watches for error screens on anything related to oembed and runs a cache clear when it sees the issue. I would have preferred writing an alter hook for handling cache and retries, but as far as I can see the only alter hook available is for modifying the response - not modifying the cache behavior.
Comment #10
astonvictor commentedD7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.