I am trying to test a servlet I wrote that processes a payapal IPN notification (my servlet is very similar to this example) - thing is even after enabling all the settings in the test account I am using the IPN notification is not firing at all.
I then found out that apparently in the sandbox the only way to test IPN is through the IPN simulator. I am trying to use it but I am getting:
IPN delivery failed. HTTP error code 405: Method Not Allowed
Does anyone have the slightest clue?
Also I am seeking ANY advice for testing IPN handlers in a straightforward manner since the IPN simulator kind of sucks (any option you pick it resets all the fields and so forth).
Any help appreciated!
I would check to make sure that your web server is allowing POST requests on your IPN handler URL. In this example, I used the PHP version of the example on the page you linked, and placed the script at /ipn.php.
I then telnet to my server. (replace with your server address)
$ telnet myserver.com 80
Trying myserver.com...
Connected to myserver.com.
Escape character is '^]'.
Paste the following into your telnet session. (replace ipn.php and myserver.com). Add a blank line after the last command.
POST /ipn.php HTTP/1.1
Host: myserver.com
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
HTTP/1.1 200 OK
If you don't see a 200 Status, it means your application is not handling POST requests properly, which is a probable cause of the 405 Error.
You should make sure that you implement a doPost() method in your servlet, as well as a doGet().
If you are able to get the requests working from the IPN simulator, and are ready to move on to sandbox testing, make sure that you have the correct Notify URL and that IPN is enabled under the sandbox seller's profile.
Also, make sure that you IPN Handler is logging INVALID requests as well, so that you know if the request was even initiated.
Finally, make sure that the IPN verification URL is set to https://www.sandbox.paypal.com/cgi-bin/webscr in your servlet. (the URL in the example you posted is https://www.paypal.com/cgi-bin/webscr)
Related
We have a curious situation with http referrer and response.
Our application is a J2EE with a WEB and EJB project. Working fine for years.
Recently, from one specific location, when user click to submit, our EJB sysout picked up trace that there was more than one submit (POST request) resulting in a null pointer. Our button have been designed to be disabled after it has been clicked. We are not sure how a subsequent request can possibly happen. In this simulation of the problem, we click once and there is only one user in the system.
Since this only occur when we connect from a particular ISP. We do not experience multiple request from other ISP locations. So we are suspecting that the ISP may have in advertently trigger a resubmit. But we are not sure. What else can we do to trace the root cause of this problem.
Thanks for your help.
Update on 12-Apr
We have installed wireshark to trace the signal from the browser side. We notice that the browser concern makes a "retry" after every 11 or 12 minutes. Would this be a normal browser behaviour?
I think we have found the cause of the problem. It is explained by by this https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries
It is something in the HTTP spec
"If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. W3 Hypertext Transfer Protocol -- HTTP/1.1
This is essentially a duplicate of Can not add account for custom Sonos service, but there's no accepted answer and I am not able to add a comment to ask if they ever resolved their issue.
I've inherited a project and am trying to add the development service. I've configured it via /customsd.htm, set the header policy to Session ID, have both secure and insecure endpoints working.
When I go to add the channel, I see the request for strings.xml. However, I never see any requests come in for getSessionId. Meanwhile the SONOS reports "Account Not Found. ***** server did not recognize your login information." I am able to make the request with SoapUI, and I get a valid response.
If it's worth mentioning, I am in SONOS' beta program and am on version 6.2, build 31926010 (Mac desktop app).
UPDATE:
While I'm not sure there's anything useful here, looking at logs at [deviceIP]:1400/support/aggregate, I see the following. Note that the redacted URL and IP do resolve. IP is for a loadbalancer, URL is behind it.
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) dns(1): [redacted URL] -<![CDATA[>]]> [redacted IP]
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) control_client(1): getSessionId failed, res = 1000, tvStart = 1456679262 s 250163 us, m_tvConnectDone = 1456679282 s 250162 us, m_tvDone = 1456679302 s 250162 us, tvNow = 1456679262 s 509982 us
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) soap(1): - param username = [redacted username]
UPDATE #2:
I inspected the packets via Wireshark, and behavior of the production service and development one seem the same except that for the production service, the controller / my computer kicks off a POST request to the Sonos before the server hangs up. That process, outlined in red in the attached image, does not occur for the customsd service.
I also experimented with using the production service endpoints in the customsd configuration, but that request failed in the same manner. FWIW, all ssl_validation tests pass just fine, as do various content tests.
For want of a trailing slash...
I finally sorted this, and it was incredibly minor. In the customsd configuration, my endpoint urls did not have a trailing slash. Adding them made it all work.
I finally realized this when I decrypted the calls the controller made to the server for both the production service and my customsd service registered to the production endpoints. The call made by the customsd service was getting back the load balancer's 400 error. The only difference between the calls were the headers, specifically:
Production service: POST / HTTP/1.1
Dev service : POST HTTP/1.1
LB properly said the call was invalid. Adding the trailing slash made it all work.
For what it's worth, I'm pretty sure the URLs without trailing slashes worked both via curl and, I believe, via SoapUI. The Sonos controller requires them, however.
Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.
I've recently started using soapUI 4.5.1 and I'm still not familiar with all the settings. I've set up a few web requests and all but one are working correctly. I'm trying to send content of type application/xml but I'm getting:
org.apache.http.client.ClientProtocolException caused by org.apache.http.ProtocolException: Content-Length header already present.
The same request always worked fine for me in 4.5.0. Content of request is something like this:
POST http://exampleHost.com/exampleRequest HTTP/1.1
Accept-Encoding: gzip,deflate
Accept: text/xml
Content-Type: application/xml
Content-Length: 456
Host: exampleHost.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Followed by the xml.
I take it that content length is sent twice, but I don't know where, because I haven't set it anywhere. SoapUI is showing Additional HTTP Headers for this message as 0.
Any pointers would be great!
I got the error to go away (in SoapUI 4.5.1) by checking the Authenticate Preemptively flag in
Preferences -> HTTP Settings -> Authenticate Preemptively
I got in touch with SmartBear support, the problem seems to have been fixed in the latest nightly build available # http://soapui.org/Downloads/soapui-pro-nightly-builds.html.
I encountered the same problem using an authenticating development server that was requesting user credentials but actually accepted a blank or any other password. So I was leaving the password blank which worked fine in soapUI 4.5.0, but failed the way you described in 4.5.1. But I found that simply putting some text into the password appears to fix the problem.
Don't know if this relates to your case, but just in case it is useful.
I faced the same issue with Soap UI pro version 4.5.1.
Finally figured out that the issue was with proxy settings.
Resolution:
Adding the target server in Exclude List for Proxy Settings has
resolved the issue. This is the case even if the end point url is a
local host.
Preferences --> Proxy Settings ---> Exclude
can specify mutliple servers by comma seperated values
Research / Observation on my system:
Strangely the same test suite runs without an issue on other system
within same office. Must be something to do with the way systems are
configured.
Playing with Proxy settings in Internet Options has no
effect.
For my request, Proxy authentication was required. But when
i enable Proxy settings i get Http Client protocol exception with
duplicate content length error.
We can find this from the http log
once the request is sent...But we don't have an option to configure
it.
An interesting observation was that one of the content length
header was in Incoming Request and the other one was in Outgoing
Request...This shouldn't throw off the request though.
Another way to cause this error is to call the web service with the wrong password (I was told wrong honest) too many times and get your account locked.
As soon as the password was reset and the account unlocked the "org.apache.http.client.ClientProtocolException caused by org.apache.http.ProtocolException: Content-Length header already present" exception went away and the web service call worked as expected.
I am writing one Web Application using XUL. In that Iam using AJAX XMLHttpRequest Object for sending request to server. When I use GPRS connection to send the request to the server from my web application the request is not going, but readyState has changed to 4 and status=0. If the request is not going out how the readyState is Changing.
The same Code working fine in local network. If I send the request to server from the browser using GPRS it is working fine. Can any body help me out in solving this problem.
Thanks in Advance.
the request is not going
How do you determine that?
Do you use the HTTP scheme? If so, status == 0 is an issue, (google says there are known quirks in Firefox).
status == 0 is also returned when the request is using a non-HTTP protocol. So if you're making a file:// request accidentally, it would explain all the symptoms...
[edit 2009-09-07]
Also found this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=488605
aborted XMLHttpRequests have status==0 since Firefox 3.
[edit] I'm not /quite/ sure, but I think that cross-domain requests that are not allowed also end up with status == 0.