Hi.

So far, I've:
1) Set up a hub on Superfeedr.com.
2) Added a feed to my Superfeedr hub.
3) Attempted to use Feeds on my website to subscribe to the feed by way of my Superfeedr hub.

Xdebug shows that the CURLINFO_HTTP_CODE result returned when attempting a subscription is:
Code 422 - Subscription was refused by your callback url (or it couldn't be reached)

Here is what I find in my webalizer access log coming from Superfeedr:
173.45.230.220 - - [07/Mar/2010:15:55:15 -0500] "GET /feeds%252Fimporter%252Ffeed%252F582?hub.challenge=9c086085c3c233ab42cf6bfd851b5cb8&hub.lease_seconds=31536000&hub.mode=subscribe&hub.topic=http%3A%2F%2Ffeeds.feedburner.com%2FJunkculture&hub.verify_token=072bde9aa547965b8e49215b3fcb8e73 HTTP/1.1" 404 -

My take from this has been:
1) Feeds is contacting my Superfeedr hub with the correct parameters.
2) Superfeedr is responding with a confirmation request using the expected format.
3) For some reason, my website/server is not echoing the hub.challenge.
4) I'm guessing that the problem is not likely caused by the Feeds code, since I cannot find anyone posting a similar problem on the Issues page or the web in general. Perhaps it has something to do with permissions settings on my server (Debian LAMP)?

I'm relatively new to Feeds, cURL, and Drush, but have spent quite a lot of time googling - find myself feeling a little lost, and would greatly appreciate a shove in the right direction.

CommentFileSizeAuthor
#3 735444-3_call_user_func.patch734 bytesalex_b
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

Doug - it looks like you're doing everything right. Some ideas:

* Have you tried pointing feeds to Google's hub (e. g. by subscribing to a feedburner feed). Do you get the same error?
* Have you added your username/pw to the superfeedr url? My superfeedr URL looks like this: http://alex_b:xxxxxxx@superfeedr.com/hubbub
* Use HEAD as I've fixed some smaller problems with PuSH (that don't seem to be an issue here).
* Try debugging the problem better with feeds_dbg() and tail -f (see feeds.module for a better idea of what you can do w/ feeds_dbg and where you can locate the log on your local file system).

I'm going to be out for the next week, after that I'd be available on IRC to help you out better to get this working. This is very fresh functionality so I'm interested in ironing out the creases.

Doug Preble’s picture

Thanks for your quick and helpful response. Please keep in mind Alex that I'm on the steep part of the learning curve with much of this.

I've had mixed results exploring your suggestions, but ultimately figured out how to successfully subscribe to my Superfeedr hub:

* Have you tried pointing feeds to Google's hub (e. g. by subscribing to a feedburner feed). Do you get the same error?
No - I don't get the same error (http://dpreble:XXXXXXXX@superfeedr.com/hubbub vs. http://pubsubhubbub.appspot.com/). Continue reading.

* Have you added your username/pw to the superfeedr url? My superfeedr URL looks like this: http://alex_b:xxxxxxx@superfeedr.com/hubbub
Yes, I had this set correctly.

* Use HEAD as I've fixed some smaller problems with PuSH (that don't seem to be an issue here).
I ran into trouble using HEAD, but think I may have confused my problem with this other issue: "Can not delete feed_item content type" (http://drupal.org/node/654326).

* Try debugging the problem better with feeds_dbg() and tail -f (see feeds.module for a better idea of what you can do w/ feeds_dbg and where you can locate the log on your local file system).
When it finally sunk in that the response from Superfeedr.com containging the hub_challenge was not something I could troubleshoot using xdebug and that I should not only set the feeds_debug variable to TRUE (using Drush) but also sprinkle feeds_dbg('Infomative ' . $messages) liberally throughout the code, then I started getting somewhere. At first, I determined the problem was in the verifyRequest function of PuSHSubscriber.inc, but in the end, the real culprit was this line:

File: PuSHSubscriber.inc
Function: protected function loadSubscription()
Line: return call_user_func("{$this->subscription_class}::load", $this->domain, $this->subscriber_id);

It seems different versions of PHP require different syntax for call_user_func. When I change this line to the following, everything works great:

return call_user_func(array($this->subscription_class,'load'), $this->domain, $this->subscriber_id);

I'm using PHP 5.2.0. Funny thing is I had been getting an error message about this line when I tried deleting feeds ("Unable to call PuSHSubscription::load(superfeedr,x"), but I figured the error was due to the fact that the feeds were never being successfully created, and would go away when I solved the creation problem - turns out it WAS the problem.

Okay, now for the somewhat unsettling part. Even with the line that did not work with Superfeedr.com, the Google hub was returning a successsful result:

Superfeedr returned: Code 422
Google returned: Code 204

With the line edited:

Superfeedr returned: Code 204
Google returned: Code 204

The Superfeedr results make more sense to me - it's almost as if the Google hub takes whatever response you send and says "good enough for me". Any thoughts?

alex_b’s picture

Status: Active » Needs review
FileSize
734 bytes

it's almost as if the Google hub takes whatever response you send and says "good enough for me"

That might well be the case as the hub implementations are very young.

The call_user_func() modification you did complies with PHP documentation, the current implementation of PuSHSubscriber.inc does not. Patch attached.

I recently found that drush needs to be invoked with the -l parameter specifying the full base URL of the Drupal site so that PuSH works correctly. I think you haven't run into this but just in case: #743368: $GLOBAL['base_url'] set to http://default

alex_b’s picture

Category: support » bug
Priority: Normal » Critical

Let's get this into the next release.

alex_b’s picture

Status: Needs review » Fixed

This is committed now. Thank you.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.