Form being randomly submitted as GET instead of POST

Question

This is kind of crazy.

Here's a form on our OpenID provider:

  <form method="post" action="/affiliate/form/login/submit?affId=7" autocomplete="off">
    <table class="position-table">
      <tr>
        <td class="input-td">
          <input class="framed-text-field" type="text" name="email" id="email" value="" maxlength="100" />
          <span class="form-help">[email protected]</span>
        </td>
        <td class="input-td">
          <input class="framed-text-field" type="password" name="password" id="password" />
          <span class="form-help">Password</span>
        </td>
        <td></td>
        <td class="input-td">
          <input type="submit" class="affiliate-button" value="Sign In" />
        </td>
      </tr>
    </table>
    <input type="hidden" id="fkey" name="fkey" value="REDACTED" />
  </form>

This form is part of a page (at /affiliate/form/login) hosted in an iframe. The iframe is served over HTTPS, the host page over HTTP. You can see this in action at /users/login using an incognito/private-browsing/porn-mode browser window.

So here's the problem, periodically (but not consistently) a user will GET instead of POST to this url. This is an absurdly low occurrence, affecting less than 50 total users to date.

I'm tempted to just dev/null these errors (no action method etc. etc.), but...

These look like real users: wide spread of IPs, varied and valid user agents, and believable timings. Frustratingly, the same users sometimes successfully POST the same form just a bit later.

Any ideas what might be causing this?

Ideas I've had and discarded:

• HTTPS accelerator or load balancer munging requests

• checked incoming logs, they match what's getting to the app

• ASP/.NET request parsing error

• Compared incoming to logged Request values, they match

• Buggy browser

• Logged occurrences in multiple Chrome versions, FireFox 4, Safari, and Mobile Safari

• Bots, or crummy browser extensions

• Wide browser, IP, and OS spread.

My current best guess is that the ?affId=# in the action is tripping something (though not consistently, again). This is basically voodoo debugging, so I'd love a more authoritative explanation.

---

Update: Tried my voodoo fix (<input type="hidden" name="affId" value="#" /> and so on), and deployed. Haven't got a repro, so I'm just letting it bake.

We see a couple a day on average, so if this bakes for 2+ without issue I'll post it as the answer.

---

Second Update: Nope, still occurring. Much less frequently however. I'm gathering more data to see if there is any commonality in terms of browsers or operating systems.

Operating theory as to why removing ?affId=# from the action has reduced occurrence is buggy proxies in front of clients optimistically fetching "things that look safe to GET". This is a wild guess, so treat it with a grain of salt.

---

Third Update: More evidence for bogus proxies. Querying logs for affected IPs (over a much longer period of time), and many of them have much higher request rates than most unaffected ones. Its not 100% cut and dry, and I'm sure some frustrated refreshing is increasing the counts a tad but... its still a reasonable indicator (the difference is 5x or so the # of requests in the same period for the affected IPs).

At this point, I'm moving onto detecting the error has occurred and providing better error messages and guidance. Rather unenthusiastic about actually getting an authoritative answer, especially as that answer seems likely to lie in the realm of "code I don't control".

Answer 1

Some ad-blocking browser extensions like AdBlock Plus Popup addon 'probe' companion pages to determine their real URL before deciding whether to block them. Specifically, the aforementioned Popup addon does this with HEAD queries by default but can be set up to do GET queries.

Answer 2

Had a similar problem with Chrome users and the cause was if someone submits a form using shift+enter in google Chrome, browser will open new tab and make GET request with no parameters. Since people often have uppercase / special character as last character of a password, they press enter before releasing the shift and then GET request is issued.

I see that you mentioned Chrome first when enumerating browsers so if issue happens in Chrome more often, it's probably because of this reason.

While this is probably not the only issue you have, it probably contributes.