#2453 RI and http responsecodes

[Narasimha Sharoff]

This issue was reported by Dave Blaschke.
Summary:
RI introduces delivery retry attempts when the listener does not acknowledge the receipt of indications via HTTP OK (200) response.
However, some response codes indicate an error where retry should not be attempted.
400 - Bad Request
501 - Not Implemented
and may be 500 - Internal Server Error
---------------------------------------------------------------

[Narasimha Sharoff]

3527920-patch

[Narasimha Sharoff]

The patch discards retry attempts when listener sends 400 or 501 codes.

[Narasimha Sharoff]

3527920-git-patch

[Narasimha Sharoff]

patch applied to CVS
patch applied to GIT

[Michael Chase-Salerno]

I believe I found a problem with this patch.

When curl has a non-http error, like not being able to resolve the hostname, the http response code will be set to 0. It never got to an http server, so it doesn't have a valid http response code. rv (the CURL error code) will be set to something other than 0.

When this happens, the case statement that was added will fall through to the default case, which will assign the http response code (which is 0) to the rc of getResponse. This causes the caller to think the indication succeeded and not attempt a retry.

I think the right thing to do in this case is to assign the value of rv to rc. The attached patch shows that fix. If the http response code is non-zero it will return that, otherwise rv will be returned.

In order to repro this, just create a destination with a hostname that does not resolve and attempt a delivery to it. You should see a message like this in the 512 trace output:

[1] [06/06/2012 13:54:19] 17339/0xb60b2b70 --- indCIMXMLExport.c(428) : --- url: http://zzzzzzzzzzzzzzzzzzzzzzzzz.comz rc: 0 CURL error: 6 (Couldn't resolve host name)

note the rc of 0 despite the error message.

[Michael Chase-Salerno]

Suggested fix for non-http errors.

[Michael Chase-Salerno]

Fix applied to CVS and Git