fetch_feed fatal memory error

[dangayle]

If you put too large of a feed into the function fetch_feed() a memory error will occur, flushing everything in the buffer, and WP will exit with a fatal error.

Increasing the WP_MEMORY_LIMIT fixes the problem, but ideally, shouldn't the feed be buffered away from WP, so that whoever controls the provider end of the feed doesn't have the power to cripple your blog? Parsing any large XML document like this as a document tree has a tendency to run into memory allocation errors, RSS being no exception.

The example warning given when wp_debug is true:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1158121 bytes) in /home/www/public_html/wp-includes/wp-db.php on line 478

[Denis-de-Bernardy]

Replying to dangayle:

If you put too large of a feed into the function fetch_feed() a memory error will occur, flushing everything in the buffer, and WP will exit with a fatal error.

Increasing the WP_MEMORY_LIMIT fixes the problem, but ideally, shouldn't the feed be buffered away from WP, so that whoever controls the provider end of the feed doesn't have the power to cripple your blog?

To me, that mostly sounds like a great plugin idea to break splogs. ;-)

[dangayle]

Replying to Denis-de-Bernardy:

To me, that mostly sounds like a great plugin idea to break splogs. ;-)

You mean, purposely INCREASING the size of your feed to cripple the spam blogs that are consuming your feed? That's dirty. Not as dirty as the spam blogs, but still. Dirty.

[hakre]

Related: #13847

[nacin]

Beyond checking the content length and doing some math to estimate if we'd be able to handle the full feed, I don't see what we could do here.

[westi]

All we could do would be to do some preventative code using a transient set before the fetch and cleared afterwards to block the next one. i.e. mutexing around the call so we only do once every <period>

But this feels like an edge case and I agree with closing for now.