Fake Response Server: Slow response time generator

homer_sleepingHere is another quick tool built on GAE. 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 by 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 endpoint somewhere I figured someone else out there might benefit from a quick public version of this system. So, I created fake response server. The first default endpoint available sleeps for a variable time.


and add a sleep param to change the sleep time seconds


(The default is 10 seconds)

Nothing major, but why not publicize the tool in case it can help some other shmuck out there like me :)




Updated Oct 2015:

Added support for POST and PUT methods

Added support for OPTION method


Updated Feb 2015:

Added params to change response status (500, 404, etc), and allow for setting a return a JSON package. It now includes instructions built into the response as well.





23 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?

    • 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?

  4. great tool but frustrated because curl -i ‘http://fake-response.appspot.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

    • 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 :)

      • 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://fake-response.appspot.com/ works as described above
        http://fake-response.appspot.com/ – DOES NOT WORK because the OPTIONS request refuses to follow the HTTPS redirect

        • 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?

        • 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.)

          • 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

Your email address will not be published. Required fields are marked *