I need help to figure out how to debug my problem.
I've got an ajax request being sent to my site.com/api/test?stuff with the correct headers in the beforeSend() and everything. But I get NO results back, no information back, when I run it in Postman I just get an infinite loading lasting forever with no errors returned. I don't know where to start looking for answers.
It does work locally and in my development area, but in production it does not. So that means the API in itself should be working, but I can't understand why does it give me an infinite loop when I try to access it in prod.
How can I debug this request ?
Related
So I made a copy of my jmx file and obfuscated the domain to include here. Be kind. I am a load testing noob. :)
I have a load testing target. I must be on the VPN to access the target's website. When connected to the VPN, my load test numbers make no sense. This is cool. I am not convinced I have the test created correctly. But what is weirder still is that when I am NOT connected to the VPN the requests receive a response. The results tree has pretty little green checkmarks (well really shield icons). But there is no way it should have been able to communicate with the server. But when I look at response body, it is a very reasonably approriate response body.
My jmx file is too big. I will try to attach it. But does anyone have an explanation for what might be going on? Or what I might have done wrong?
These "pretty little green checkmarks" doesn't mean that you're hitting the correct server, JMeter automatically treats HTTP Status Codes below 400 as successful so my expectation is that you're basically hitting some form of VPN web gateway login page or something like this and JMeter considers these redirects as successful responses.
You can inspect request and response details using View Results Tree listener and see what exact host you're hitting and what does the response say.
Going forward in order to protect yourself from these "false positive" results you can consider adding Response Assertions to your requests to ensure that response contains what it is supposed to be containing or alternatively doesn't contain errors
I am running into an issue with an API Gateway/Lambda implementation. I've written a authentication service that works across subdomains and appears to work fine in most cases. Testing locally works perfect.
When it is deployed to AWS, with the API in a Lambda with an API Gateway in front of it, the log in system works great. The user can login, which returns a 200 and then a ReturnClaims-style endpoint returns their access, and other useful account bits.
The problem arises that after a little while (like an hour or so usually) the ReturnClaims endpoint will continue to return a 200 but the response is now empty when the page is refreshed.
The HTTP-Only cookie still lives in the browser and it's not throwing any errors.
When running locally, this issue doesn't arise at all. The user can refresh for as long as the cookie has and JWT has been instructed to last (which is 30 days but I've adjusted this for testing purposes as needed).
I am hoping someone might have an idea of what might cause an endpoint on AWS to function in this manner, perhaps some life setting I am unaware of?
I appreciate any advice or suggestions. Thanks!
I am trying to take advantage of the tracking features supplied by vast. On each quartile I am sending an AJAX request (I have tried get, head, and post) to the url provided within VAST XML but every time I get 405'd.
Thank you!
Can you provide one of the quartile URLs so we can trace it?
What happens when you call that quartile directly in the browser, does it work outside of your Ajax call?
Are your other events working fine? such as impression, start play, click, etc..
From the HTTP methods you tried GET should work, but POST should not be used with the VAST trackers. Hopefully the server you are hitting is not giving you an incorrect error code, masking an internal error.
I am sending an ajax request to a controller/action in Codeigniter and it does some manipulation and sends a response.
The response that I get is accurate but the time taken for it to send the response is 4-5 seconds which is huge.
I was able to debug and pin point the cause of this lag. At the end of the method I am sending a mail. I am using mail() function here. I am even suppressing the error by writing #mail(), so on localhost it is not giving any error and executes well on the live server.
But even though there is no error, there is lag in both the environment i.e. locally and on Live server. I am not sure what the problem is.
Now as soon as I remove/comment out the mail() function, the response is instantaneous and lightning quick.
Please let me know what might be the issue what might be the possible solution.
Thanks in advance.
PHP mail() is very limited. Try using the code igniter Email class: http://codeigniter.com/user_guide/libraries/email.html
I am trying to implement Google Check out (GCO) on a new server, the process seemed to work fine on the old server.
The error from GCO integration console is the timeout error you might expect if there is load on the server and/or the response takes longer than 3 seconds to respond.
To perform a test (not integrating with my database), I have set some code to send an email to me instead. If I hit the https url manually, I get the email and I can see an output to the screen. If I then leave it as that, Google still returns the Timeout error and I don't get an email. So I have doubts as to whether google is even able to hit the https url.
I did temporarily attempt to use the unsecure url for testing and indeed I received the email, however this solution isn't the route we've developed for, so the problem is something to do with the secure url specifically.
I have looked into the certificate which is a UTN-USERFirst-Hardware which is listed as accepted on http://checkout.google.com/support/sell/bin/answer.py?answer=57856 . I have also tried to temporarily disable the firewall with no joy. Does anyone have any sugestions?
Good to hear you figured out the problem.
I'm adding the links below to add a litle more context for future readers about how Google Checkout uses HTTP Basic Authentication:
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#urls_for_posting
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#https_auth_scheme
http://code.google.com/apis/checkout/developer/Google_Checkout_HTML_API_Notification_API.html#Receiving_and_Processing_Notifications