Fake Response Server: Slow response time generator

Here is another quick tool built on GAE AWS. This one is super simple, but pretty handy. Today Twitter went down, and somewhere in our system we were using the Twitter API to display one of our status feeds. Them being down became us being slow.

Well, I wanted to do some quick tests to keep this from happening again, but byt the time I got to it Twitter was responsive again. To fix it I would need to create a bad URL. The crappy thing is I wanted a slow response time, not exactly a bad response/error. Creating a 404 error is easy, just go to some url that doesn’t exists and test. But I want a slowwwww response.

I quickly searched Google for something I could use, and didn’t find one. When I realized I would have to create a fake pause endpioint somewhere I figured someone else out there might benfiift from a quick public version of this system. So, I created fake response server. The first default endpoint available sleeps for a variable time.

fake-response.appspot.com (Update: Moved to AWS)


and add a sleep param to change the sleep time in milliseconds

fake-response.appspot.com?sleep=5 (Update: Moved to AWS)


Nothing major, but why not publicize the tool incase it can help some other shmuck out there like me πŸ™‚


24 thoughts on “Fake Response Server: Slow response time generator”

  1. Thanks, this seems useful (having same problem as yourself with external social media sites taking too long to respond)

  2. Thanks. pretty cool. Just used it to test some of my app’s timeout handling.
    Would be useful if you could also get it to start responding but really slowly.

  3. Hey guys. Any other features you would find useful? I was thinking about adding the ability to get a mock response JSON that can be set by the developer in the portal to allow the developer to test out different endpoints…..Thoughts?

  4. K all. I added a JSON data param and instructions πŸ™‚ Thanks for the feedback and LMK if you want more.

    1. Looks like my original response two months ago didn’t go through! Sorry, for the delay. I’d be happy to add what ever makes other developer’s lives easier. What did you have in mind? Simply add the ability to accept post requests and thats it? While I’m mucking around with the code base, is there anything else you’d like?

      1. Great, thanks!
        I think that’s it, I only needed the existing functionality for POST request.

  5. great tool but frustrated because curl -i ‘https://6wrlmkp9u2.execute-api.us-east-1.amazonaws.com/?sleep=3&status=500’ -d “fred=5” -X OPTIONS gives a 405 (but works when you drop -X OPTIONS) … -X OPTIONS is being sent when making a request using angular’s http.post in Firefox … annoying!! please can you support -X OPTIONS … a similar problem and solution is discussed here … https://social.msdn.microsoft.com/Forums/en-US/0492df60-b74a-4bf3-9353-744a54439f0e/the-http-method-options-is-not-allowed?forum=netfxnetcom … thanks

    1. Ah I found out what the issue is … when POSTing to your server Angular makes an initial OPTIONS request before sending the POST because its a X-domain request. Angular is checking to see if you have the necessary Access-Control-Allow-Origin headers before POSTing.
      Because you only allow POST, PUT and GET the OPTIONS request responds 405 and the POST is never made 😦
      Please fix this bug by supporting OPTIONS requests – See http://zacstewart.com/2012/04/14/http-options-method.html for more details about the OPTIONS method – thanks πŸ™‚

      1. UPDATE …

        In angular http.post works as follows …

        http.post makes a pre-flight options request – this takes sleep seconds to respond and responds with status – The HTTP POST is never made – I guess if status was 200 then it might … That would mean a sleep delayed OPTIONS request followed immediately by a sleep delayed POST request.

        For my purposes this is all I need but a better solution would be for OPTIONS to reply IMMEDIATELY with …
        200 OK

        Which should then result in the POST request being made by Angular

        https://6wrlmkp9u2.execute-api.us-east-1.amazonaws.com/ works as described above
        https://6wrlmkp9u2.execute-api.us-east-1.amazonaws.com/ – DOES NOT WORK because the OPTIONS request refuses to follow the HTTPS redirect

      2. Before I look at the SSL part of your question is like to understand the OPTIONS issue. Based on your original post I thought you were testing the OPTION method for some reason. The way understand it, (based on my experiences with Browser AJAX calls) the OPTION method is sent first to check if a CORS (or header mod’ed) request is allowed. If it is the caller then sends a second request with the original method (e.g. POST)

        The issue with how it is setup now is the OPTION request sleeps as well as the POST, and that is not something you want (and I can see why) I’ll think through solutions , but, first, are we on the same page?

      3. Okay. I was able to replicate your OPTIONS issue using a jQuery AJAX request. I resolved it by having the OPTIONS request return a response with the CORS required headers and nothing else; no sleep or data based on params etc. The AJAX calls work now, but since I don’t know how to quickly spin up an Angular project I can’t be 100% sure it will work for you. It should though since the CORS request/response procedures are pretty standard. Feel free to give it a shot and let me know. (Oh yeah, I also removed the HTTPS redirect stuff for now until I figure out how to do it properly.)

      4. Sean, just tested it, works amazingly well πŸ™‚ Absolutely no issues now – many many thanks – great service – I will be using it a lot!!

Leave a Reply to CCCrazyPanda Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.