1

In our server logs, we see that some HTTP requests contain the parameter bmi_MfsTid=<number>. We are not using this parameter. Is there a known client or proxy that appends this?

3
  • I seem to recall a similar question where a Chrome plug-in was doing this to avoid cached pages.
    – closetnoc
    Feb 26, 2015 at 4:30
  • Found it! It is not exactly the same, but close enough to give you an idea. webmasters.stackexchange.com/questions/72401/…
    – closetnoc
    Feb 26, 2015 at 4:32
  • We're seeing this particular parameter in our logs from a very specific IP range and it's causing signed URLs to fail authentication. The traffic comes from the Safari browser on iPhones with iOS versions ranging from 8.1.1 to 9.2. My guess is that this is coming from some hardware device on a carrier's network. Would this explain what you see in your logs?
    – Dov D.
    Dec 22, 2015 at 16:44

1 Answer 1

1

I'm seeing this when using the UK mobile network, EE, with HTTP requests that result in a 302 Redirect. The resulting Location header in the response contains the bmi_MfsTid parameter on the query string.

I tracked this down to requests that include a Range: HTTP header and an iOS User Agent such as:

E.g.

Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A356 Safari/604.1

AppleCoreMedia/1.0.0.16E227 (iPhone; U; CPU OS 12_2 like Mac OS X; en_gb)

Obviously, something on the mobile network is injecting the bmi_MfsTid for some reason. I'm not sure if it's relevant, but EE is a pure IPv6 network that uses DNS64 and NAT64, so it's possible it's the NAT64 proxy is adding this header.

Solution:

  • Remove the Range header.
  • Or: Alter the User Agent to a non-Apple one
  • Or: Change request to HTTPS so that EE is unable to see and change the body

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.