Curl RETURNTRANSFER данные? Время? проблема и несколько идентичных постов - PullRequest
0 голосов
/ 14 октября 2010

Я сталкиваюсь со спорадической проблемой с параметром curl RETURNTRANSFER. Я не уверен, что я пропустил что-то в своем коде, что вызывает его, или это просто плохо документировано, и я не знаю о работе RETURNTRANSFER.

Я использую curl (через php) для отправки xml-данных через POST внешнему слушателю. В случае успеха слушатель отвечает и возвращает тот же xml с одним или двумя заполненными полями, которые я отправил через пустое поле. например. <Status /> становится <Status> Принято </Status>. Примерный размер полного XML-запроса POST - [upload_content_length] => 1414. Отправляется уникальный идентификатор (сгенерированный на моей стороне), если слушатель получает повторный идентификатор, он отклоняет данные xml и отвечает сообщением об ошибке в виде простого текста.

Это работает в 99,9% случаев.

Код скручивания:

$header[] = "Content-Type: text/xml";
$header[] = "Content-length: ".strlen($post_string);
$x = curl_init("https://xyz.com");
curl_setopt($x, CURLOPT_HEADER, 0);
curl_setopt($x, CURLOPT_HTTPHEADER, $header);
curl_setopt($x, CURLOPT_POST, 1);
curl_setopt($x, CURLOPT_POSTFIELDS,$xmldata);
curl_setopt($x, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($x, CURLOPT_REFERER, "https://mypage.com");
curl_setopt($x, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($x, CURLOPT_PORT, 443);
curl_setopt($x, CURLOPT_SSL_VERIFYPEER, 0); //to allow self-signed SSL cert
curl_setopt($x, CURLOPT_SSL_VERIFYHOST, 0); //to allow self-signed SSL cert
curl_setopt($x, CURLOPT_TIMEOUT, 30);
curl_setopt($x, CURLOPT_FORBID_REUSE, TRUE);
curl_setopt($x, CURLOPT_FRESH_CONNECT, TRUE);
curl_setopt($x, CURLOPT_BUFFERSIZE, 64000);
curl_setopt($x, CURLOPT_VERBOSE, 1);
$listenerresponse = curl_exec($x);
$info = curl_getinfo($x);
curl_close($x); 

Недавно я обнаружил ошибки, в которых ошибки слушателя встречались с дублирующимися идентификаторами.

Мои журналы показывают временную шкалу, как это ::

  1. curl POST уникального идентификатора "12345678"

  2. слушатель отвечает «Дубликат ID» в 2010-10-13 17: 27: 59

  3. слушатель отвечает «Принят» 2010-10-13 17: 28: 06

Первоначально я думал, что предыдущий идентификатор был каким-то образом кэширован и отправлялся по ошибке, но это не так. Слушатель получает правильный идентификатор. Журналы слушателей показывают это с немного другой хронологией:

  1. Слушатель отвечает «Принят» в 2010-10-13 17: 27: 48

  2. Слушатель отвечает «Дубликат ID» в 2010-10-13 17: 27: 58

Насколько я понимаю, я ожидаю, что поток curl будет ждать ответа, а не отправлять другой запрос. Прав ли я, предполагая, что проблема связана с сетью - возможен сброс пакетов / что-то подобное? Любые предложения о том, как предотвратить это, были бы очень признательны. В идеале я хотел бы, чтобы curl отправлял и ждал полного ответа перед отправкой другого запроса ... Есть ли возможность указать это? Пожалуйста, помогите: -)

Спасибо за внимание.

S.

1 Ответ

1 голос
/ 14 октября 2010

По умолчанию CURL будет блокировать (например, ждать) запрос до завершения, прежде чем вернуться из curl_exec() ca.,Похоже, вы не используете multi-curl (который допускает множественные параллельные запросы), поэтому не должно быть никакого способа смешать пакет из запроса A с пакетами из запроса B, C, ... RequestA завершится и вернется до того, как будет выполнен запрос B.

У вас есть контроль над сценарием слушателя?Возможно, вы захотите включить токен, который вы генерируете с каждым запросом, поверх этого «уникального» параметра ID, и чтобы слушатель выплевывал его в любых сообщениях об ошибках, чтобы вы могли точно определить, какой запрос вызвал ошибки дублирующегося ID.

...