0

I have been trying to figure this issue out for a while re-checking my code and searching on the internet, I found some possible answers if the cause was something else but nothing exactly like I have here, so I thought it was time to post my first question, hopefully this doesn't belong on stackoverflow.com instead:

In the log file below you it seems the client is sending two requests for the same resource but with different IPs at the same time. Each client has a unique ID "12345" in the case of this client. Part of my workflow is after we get to the last page, page 8 -> "/app/page/8/12345" the app sends out an email.

Well as far as I can tell these duplicate requests to the app is what is causing duplicate actions in my controller causing duplicate emails.

So my question is what could be causing these duplicate requests and what can I do about it?

  1. Could it truly be the client sending two requests, possibly because they have two IPs configured or perhaps they are going through a VPN and both IPs are being seen on my server?
  2. Could this be a configuration issue on Apache or Passenger Standalone that I missed.
  3. Is there a standard way to handle these types of requests, This is the first time I have seen this type of issue.

This does not happen for every request or every user, it just seems to happen for some users. When I test, the log files just show one request when I hit the browser Submit button no duplicates.

Log File:

.
.
.
.

Started GET "/app/page/5/12345" for 189.19.xxx.xxx at 2013-02-17 22:44:46 -0800
Processing by MainController#page as */*
  Parameters: {"page_no"=>"5", "id"=>"12345"}


Started GET "/app/page/5/12345" for 184.102.xxx.xxx at 2013-02-17 22:44:46 -0800
Processing by MainController#page as HTML
  Parameters: {"page_no"=>"5", "id"=>"12345"}
  Rendered main/_range_table.html.erb (7.1ms)
  Rendered main/_range_table.html.erb (7.2ms)
  Rendered main/page.html.erb within layouts/main (18.3ms)
Completed 200 OK in 29ms (Views: 17.5ms | ActiveRecord: 4.2ms)
  Rendered main/page.html.erb within layouts/main (17.6ms)
Completed 200 OK in 26ms (Views: 17.2ms | ActiveRecord: 3.3ms)


Started POST "/app/page/5/12345" for 184.102.xxx.xxx at 2013-02-17 22:44:57 -0800
Processing by MainController#page as HTML
  Parameters: {"utf8"=>"?", "authenticity_token"=>"4exZYGAEcu4xffiBfh45u877bvF0zGpNXJhL98QLzy0=", "response"=>    {"43"=>"8"}, "commit"=>"Submit", "page_no"=>"5", "id"=>"12345"}
Redirected to http://<mydomain_here>/app/page/6/12345
Completed 302 Found in 24ms (ActiveRecord: 6.7ms)


Started GET "/app/page/6/12345" for 189.19.xxx.xxx at 2013-02-17 22:44:57 -0800
Processing by MainController#page as */*
  Parameters: {"page_no"=>"6", "id"=>"12345"}


Started GET "/app/page/6/12345" for 184.102.xxx.xxx at 2013-02-17 22:44:57 -0800
Processing by MainController#page as HTML
  Parameters: {"page_no"=>"6", "id"=>"12345"}

  .
  .
  .
  .
  .

Thanks for any help or suggestions to point me in the right direction!

tronmcp
  • 101
  • 2

1 Answers1

0

Ok I believe I have the answer to my question after much research and revisiting the legacy code in my application:

  1. Where are these requests coming from? From what I have researched and my observation:

    a. These requests have become more frequent since the first of the year (Jan 2013) but with no changes in my code, it seems something has changed on the internet possibly or with client machines or network infrastructure. I am going with network infrastructure, possibly an upgrade of some kind.... see (b.)

    b. During my research online it has been suggested that some proxy servers might re-request the URLs of their clients requests and perform additional GETs to cache these pages. I have seen this happen seconds after an initial request or up to 30 minutes later.

  2. The big gotcha... I found legacy code that was processing DB changes on GET requests, from my understanding this is a no no and all DB changes should be done on POST requests only.

So basically my code should be able to handle as many GETs as come in to the same URL without taking action beyond returning the same data every time with no DB updates.

So this has now been corrected. Hopefully this post will help someone with a similar problem!!

tronmcp
  • 101
  • 2