Обработка POST-уведомлений подписчика PubSubHubbub в произвольном типе записи WordPress

Я пытаюсь реализовать протокол подписчика PubSubHubbub с WordPress, где каждая из записей Atom канала будет сохранена в пользовательском типе сообщения для клиента, а многие поля XML будут сохранены в настраиваемых полях.

Проблема, которая была поднята клиентом, и я не уверен, заключается в следующем: когда приходит уведомление HTTP POST от концентратора с новым содержимым, клиент-подписчик (WordPress) уведомляет об успешном получении уведомления и только пытается отправить повторяйте запрос, пока клиент не отправит уведомление об успешном завершении (http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.4.html#contentdistribution).

Однако как бы вы справились с этим, если по какой-то причине сценарий остановился посередине? Как вы могли убедиться, что он снова получил эту ленту? Кроме того, потому что может быть около 50 статей, опубликованных последовательно.

Надеюсь, кто-то может помочь мне с этим.

РЕДАКТИРОВАТЬ:

Извините, я не очень хорошо выразился. Меня в основном беспокоит то, как кто-то может защитить себя от остановки своего сценария в середине обработки XML в WordPress (возможно, в очереди в WordPress, что я не знаю, как это сделать, или сохранить временный файл XML и отбросить в конце)?


wordpress push subscriber websub
person vitorf7    schedule 05.12.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Во-первых, PubSubHubbub — это открытый протокол. Несмотря на то, что изначально он был разработан для каналов RSS/Atom, теперь он полностью независим. Также не имеет значения, идет ли речь о ленте Wordpress или RSS-канале любого типа, который его поддерживает (Medium, Blogger... и т. д.).

Теперь при получении уведомления подписчик должен ответить кодом состояния 2XX:

Успешный ответ от URL-адреса обратного вызова подписчика ДОЛЖЕН быть кодом успеха HTTP [RFC2616] (2xx). Концентратор ДОЛЖЕН рассматривать все остальные коды ответа абонента как сбои; это означает, что подписчики НЕ ДОЛЖНЫ использовать перенаправления HTTP для перемещения подписок. Тело ответа от подписчика ДОЛЖНО игнорироваться хабом. Центры ДОЛЖНЫ повторно отправлять уведомления до тех пор, пока они не будут успешными (до некоторого разумного максимума в течение разумного периода времени). Подписчики ДОЛЖНЫ отвечать на уведомления как можно быстрее; их код успешного ответа ДОЛЖЕН указывать только на получение сообщения, а не на подтверждение того, что оно было успешно обработано подписчиком.

Как видите, хаб может повторить попытку в случае сбоя. Итак, у вас есть хоть какой-то запас для очень временных и спорадических проблем... Тем не менее, вы должны убедиться, что ваш скрипт не будет остановлен посередине.

person Julien Genestoux    schedule 08.12.2014