Fish · Back garden Fish – hidden gardens

Talk about the problem that Ajax requests will be repeated in wechat pages

This article was last updated on
Monday, August 29, 2016 9:25 PM(a year ago), may fail because there is no update. If you find that this article is invalid and needs to be corrected, please leave a message to the blogger

background

It was a big hole, and it took me an awful lot of time.

Here’s the thing. In recent days, I made a slip page in wechat to register an account. Registration is very simple, enter mobile phone number – verify SMS verification code – fill in some information – registration success.

As a single page operation, all requests interact with the server via AJAX, which is a common idea. The only thing is, the last step is super long.

The reason for the extra length is that creating an account requires the creation of hundreds of tables and countless initialization operations, so an optimistic estimate would take at least eight seconds to succeed.

Why is it so slow, you might ask, to create so many tables?

Forgive me for not wanting to say it, as it is irrelevant to this article.

The first step is to create a placeholder for the user’s email address: create it as basic information, and do not allow repeated creation.

OK, that’s the background.

Until the launch

Development, testing, and internal testing were perfect without any problems.

But after the launch, a test suddenly raised such a problem: when registering in wechat, any mailbox would prompt that the mailbox was already used.

Faced with such an error and the same error no matter how you change your email address, everyone is stunned.

Inner OS: What the hell is that?

Back end (Java, yes, syntax and performance terrible Java) : this is a very low-level BUG, it is obvious that the server returned the error message for the first time and they cached the record directly, so there is no validation behind it.

I haven’t contradicted it yet. It’s straight in the face.

Test: This is how I typed it the first time. Java:…

Java was lost in thought. In any case, I was optimistic that it was not my problem and sat there watching them. Later, Java reluctantly went back to the database and found that the mailbox did exist. Java students a clap thigh, said oh you this group of tests are pigs ah, this obviously exist!

The test of the students a face meng forced, reluctantly used a small email re-registration, the same mistake. Java classmate a check database, “line not line you, this mailbox still have ah”. Test classmate a face is vacant, say I prepare to apply for a QQ again, your ya don’t quarrel…… Please check whether the mailbox XXX exists. Java: This mailbox does not exist. The test students bowed their heads and said, “the same mistake.” Java students bowed their heads to check, alas day ah, how the database has a record, not return has existed yao.

And then everyone was silent for a while, and finally they all turned their heads to me together, like this.

They: You must have made repeated requests and only received the last one as a result. I directly shake the pot: don’t look at me, close my hair matter, all browsers have tested, button at the time of the request are disabled impossible to repeat click, send request status are marked impossible to repeat hair, how possible hair twice, you don’t make, the evidence is disorderly talk.

Java students go back and add Log output to the code, and then test and see the output.

Then they saw the bad news for me:

“Wooden fish you see, you are sent two requests!”

I looked at the record, and sure enough there was a two seconds difference, there were two requests to start executing the record…

I……

Long search for the cause

Reluctantly, I came back to the front end.

However, no matter how I look at the code, how to debug, how to use my own wechat test, whether it is android (xiaomi) or iPhone5S, I can not detect the slightest problem. There is no program logic to send the request twice.

Good depressed… Using the MVVM framework, is there a problem with this framework?

And then I started to think it was the server. The Java backend runs on Tomcat, with Nginx in front to do the reverse generation. So I went to operations to look at Ngxin’s access logs.

After checking the related requests, it is found that there are indeed repeated requests, but the client IP address is different and the time is different. The requests from the same IP address are all in the same sequence without repetition.

So according to the Nginx log, it is clear that the client did not make a duplicate request. If it did, you should see the same IP address being repeated. What about the duplicate record on the Java side?

Looking at the naive face of Java students, I feel that it is a great harm to throw the pot to them like this.

So I in line with “there is no improvement plus mian” starting point, decided to change the front-end code.

On the first attempt, before entering the Ajax method, add a bool variable marker, mark it on entry, clear the marker after completion, check if it is marked before entering, and exit if it is marked. No improvement at all, same mistakes.

In the second attempt, I changed the Ajax method to synchronous. I directly blocked your browser operation. No improvement at all, same mistakes.

For the third attempt, mount the global Ajax hook and print the return result into the DOM after Ajax is complete. The printed message is not repeated, indicating that only one result was received, that is, the mailbox already exists.

On the fourth attempt, directly to jQuery AjaxFilter, parallel repeated Ajax requests, directly truncated. Nothing came of it.

The fifth attempt, before Ajax, sets an Alert popup warning. Magically, repeated requests are gone…

I don’t know what the fuck this is.

At this point, has been from eight in the evening toss more than ten.

In order to figure out what the problem was as soon as possible, we decided to capture the packet test. Take out your mobile phone, use wechat to visit the page to register, there is no problem at all.

Could it have something to do with the phone? That the mobile phone that appears this problem also is not a? Took a phone that had been having problems, connected it to wifi, set up a proxy and caught it with Fiddler.

Completely normal, no problems, the registration process is normal.

However, if you cancel the proxy, you will only report errors that already exist in the mailbox.

What the f * ck…

It was already past eleven o ‘clock.

At this point, they came up with a very constructive (no surprise) suggestion that the request was delayed for a few seconds because of the alert, or that this was a jQuery problem?

I reluctantly (and thought they were pure bullshit) added a setTimeout test.

The waves still sound 

What’s going on?

According to the Java output, there is a success message.

Then I display all the Ajax results into the DOM, only to find an error message, but no success message. In other words, if the request does repeat itself, the only explanation is that the js runtime error caused the corresponding message to go unprocessed.

However, the new android version of wechat has its own browser kernel, not the webView of the system, so you can only use wechat’s own tools for debugging. But at least you can test it.

Connect to the debugger, break the point, and discover that the Ajax function is called only once, no problem, but the only message you receive is an error with no normal results. So it’s not an error, it’s really not returning that result.

Seeing this result, everyone is cranky, what the hell is going on?

I originally wanted to capture packets in wechat, but to capture packets in wechat debugging tool also needs to set agent. From the previous test results, there is no such problem with setting agent, so I was stuck again.

At the moment, my heart is broken, can only really wash sleep.

Ah, the dawn

At this point, it is already more than twelve o ‘clock in the morning. In order to find the problem as soon as possible, the students at the back end of the server directly connected to the real-time output of Nginx access logs.

Magically, click register once and scroll out two logs… (Forgive me for not taking screenshots)… I a look past, ah day this is not before I saw that two IP yao, how this time still in??

The two logs have the same information, including the address, method, and UserAgent, except for the different client IP addresses. The client IP addresses are 123.151.42.57 and 211.102.210.254 respectively. There is nothing wrong with 211.102.210.254, it is the exit IP of this side, what is the ghost of the previous 123.151.42.57? I looked it up on IP138, and it was the telecom IP of Tianjin. Then the IP request is sent first, two seconds before the subsequent request, and the response status code is 499, followed by 200.

What’s wrong with the 499 status code? A search for Nginx error codes shows that this (non-standard) error indicates that the client closed the connection.

…………………………………… The client closed the connection ？？？？

The existing error in the mailbox was returned by the 200 request.

PHP students a clap thigh, god this is not said timeout yao, your ya to request a longer timeout set.

I don’t want to talk to him and I want to blow his face.

“I had already set the timeout to 5 minutes to avoid this problem.”

But at this point, I started paying attention to those TWO ips…

guess

So far, my only guess is that wechat browser requests, not necessarily directly to the server to send requests, but through some specific relay server for forwarding. As for the reasons for forwarding, they may be for retaking (retaking a PC’s web page to save traffic or fit the phone) or speeding up (compression) or security detection (blocking known malicious sites in transit). The last registration request was sent by 211.102.210.254 after 2 seconds. The last registration request was sent by 211.102.210.254. I can only explain that the timeout time of the transfer server is two seconds. In order to prevent the network problems of the server from causing users to wait too long, by default, if the request is not returned within two seconds, the transfer will be abandoned and directly initiated.

If this is the case, it would explain why two requests followed each other, with the first one producing 499 errors two seconds later. So why is this not a problem with agents? It is easy to explain that if the system is already set up to be accessed through a proxy server, the software will simply assume that there is no direct networking or easy and reliable access through a reverse proxy server, so the transfer will be abandoned.

Judging from the interval of two seconds, the timeout time is about two seconds. You can then assume that the request will return within 2 seconds and that a second request will not be raised.

Java students changed the interface, first do not do specific operations directly return success, test, sure enough, there is no such problem smoothly through the process.

This hole is also… They kept people alive until 1:00 in the morning.

Later, as an improved creation scheme, the Java side directly returns success after confirming that it can be created, and then starts the background task to create asynchronously. They didn’t check whether the creation was successful, because they thought the probability of failure was low, and even if it failed, there was no way to retry it, so they didn’t check it yet.

So far, the problem has been solved.

repeat

Now the problem is solved, but the real problem remains: I need to determine my conclusions.

According to the above judgment, it follows that:

1. When ajax requests are made directly in wechat, they are actually transmitted through some specific servers
2. This transfer is not all, and it is related to the phone and system (because wechat of my Android phone does not have this phenomenon, and the phone with this phenomenon is not a specific brand, and iPhone does not have this problem).
3. The timeout for this relay is short, and when it does, the request is quickly rolled back to non-relay mode

To determine if there was a problem, I resolved a test domain name, debug.fishlee.net, and simulated a test page with long and short requests and enabled tracing. Short requests are returned immediately, while long requests block the current operation for 10 seconds.

The test code is as follows.

The < %@ Page Language="C#" AutoEventWireup="true" % >
 
<script type="text/c#" runat="server">
 
    void Page_Load(object sender.EventArgs e)
    {
        var method = Request.HttpMethod;
        var action = Request.QueryString["action"];
        var startTime = DateTime.Now;
 
        if (method= ="POST")
        {
            if (action= ="slow")
                System.Threading.Thread.Sleep(10 * 1000);
            Response.Write((DateTime.Now - startTime).TotalMilliseconds.ToString(a));
            Response.End(a);
        }
    }
</script>
<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no" />
    <title>wxapi</title>
    <script src="http://static.fishlee.net/libs/jquery/1.12.4/jquery-1.12.4.min.js"></script>
</head>
<body>
    <button id="normalRequest" type="button">Regular request</button>
    <div></div>
    <button id="slowRequest" type="button">Slow request</button>
    <div></div>
    <script>
        $(function (a) {
            $("#normalRequest").click(function (a) {
                $.post("? action=normal").always(function (data, option, xhr) {
                    $("#normalRequest+ div").html(xhr.responseText || "empty.");
                });
            });
            $("#slowRequest").click(function (a) {
                $.post("? action=slow").always(function (data, option, xhr) {
                    $("#slowRequest+ div").html(xhr.responseText || "empty.");
                });
            });
        });
    </script>
</body>
</html>

And enable tracing in web.config.

<?xml version="1.0"? >
<configuration>
 <system.web>
     <httpRuntime targetFramework="4.5"/>
     <trace enabled="true" requestLimit="100" pageOutput="false"/>
 </system.web>
</configuration>

After tracing is enabled, you can view the tracing result by running/trace. axd.

First of all, I clicked two buttons in my wechat. The trace shows that there are only two records, and the client IP is consistent with my machine.

Then I took them to test the phones with problems, and tested them in the wechat inside, click respectively. Click the button twice and three records appear. In other words, the problem is repeating itself.

Then let’s look at each of the three requests.

The first request corresponds to a short request, which is sent and immediately successful, which is pretty mindless.

It is clear from this figure that the remote address is 123.151.42.57, which is not the exit IP for local broadband. The HTTP_X__FORWARDED_FOR header is an HTTP_X__FORWARDED_FOR header. Why? Because this header is a hallmark of an anti-proxy server, or proxy server, to tell the upstream server that it is actually forwarding someone else’s request.

Then let’s look at the second request.

The second request is a slow request, which is not different except that the operation parameters are different, and all the information is exactly the same as the above request.

Finally, we come to the third request.

The typical difference is that the client IP is now 211.102.210.254, which corresponds to the local egress IP. In other words, this accesses the source server directly without passing through the relay server. Therefore, you can also see that the HTTP_X_FORWARDED_FOR header below is gone: it’s not a transfer.

So far, all the inferences have been proved.

conclusion

Repeat the conclusion from section 6.

1. When ajax requests are made directly in wechat, they are actually transmitted through some specific servers
2. This transfer is not all, and it is related to the phone and system (because wechat of my Android phone does not have this phenomenon, and the phone with this phenomenon is not a specific brand, and iPhone does not have this problem).
3. The timeout for this relay is short, and when it does, the request is quickly rolled back to non-relay mode

As for the transfer in the end what is the case, what is not the case, this did not find the rule, also unknown wechat embedded browser kernel behavior or system behavior.

If you have to make a substantive summary, that is, if you assume that your request is a critical request and difficult to retry still running in wechat, it is best to ensure that your interface return within two seconds, otherwise there may be very weird difficult to reproduce the problem, if the time is too long, it is best to make asynchronous.

Closing argument, it’s this transit mechanism that was really poorly designed, and I don’t know where it came from.

Until later, with the wechat debugging tool…

Actions speak louder than words. I think I can guess the cause just by looking at the problem. 23333

A trackback
Blog.fishlee.net/wp-trackbac…

AJAX
WeChat

Devart dbForge for Oracle 3.8.50
CentOS7 Change the SSH port number

• No relevant article at present!

Post my comments

Cancel the comment

Submit comments

Email me when someone replies

Submission in progress, please wait…

#

expression
Email me when someone replies

Hi, you need to fill in the nickname and email!

• nicknameNickname (required)
• emailEmail address (required)
• The urlThe url

(42)A friend is teasing

1. 

   Yu Da, could you please tell me the model of the machine that went wrong in the test? I also encountered this situation, but the test did not happen. After the launch, we could not reproduce this situation.

   iPhone10.3
   IOS10.3.2
   IPHONE

   xdt2017-07-17 08:20 (4 days ago)
   reply

   • 

     For a long time. I can’t remember. But it should be on Android, because android wechat is its own browser core.

     Chrome61.0.3159.0x64
     WINDOWS10x64

     Wooden fish2017-07-19 00:31 (2 days ago)
     reply

2. 

   Worship god, this question can only be modified backstage? Is there a way to modify the foreground request to get around this problem?

   Chrome58.0.3029.110
   WINDOWS7x64

   panchao260In the 2017-07-03 s a trap
   reply

   • 

     This…… I don’t think there’s a good way

     Chrome61.0.3147.0x64
     WINDOWS10x64

     Wooden fishThe 2017-07-03 23:50
     reply

     • 

       All right.

       Chrome58.0.3029.110
       WINDOWS7x64

       panchao260The 2017-07-04 11:53
       reply

3. 

   Big god how to solve this problem?

   Sogou
   WINDOWS10x64

   LZWThe 2017-06-23 10:20
   reply

4. 

   What does the last texture mean? If the user’s mobile phone is set up as a proxy, there will be no transfer situation? Will it appear without setting it?

   Chrome57.0.2987.133
   WINDOWS7x64

   HealerThe 2017-04-27 indeed
   reply

   • 

     Make an agent and it won’t show up.

     Chrome60.0.3111.0x64
     WINDOWS10x64

     Wooden fishThe 2017-05-27 12:56
     reply

5. 

   We also encountered this problem. When I saw the second request, I knew wechat must be the agent, but I didn’t come up with a good solution to solve it. After reading your article, I finally had the idea to deal with it.

   Chrome56.0.2924.87
   MAC OS10.10.3

   CodingRoadThe 2017-03-28″
   reply

6. 

   A similar problem occurs, except that the request is responded to within 2 seconds, but the request is still received 10 seconds later (the interval for each repeated request is 10 seconds). The client address and user-agent of the two requests are differentWhat the hell is this? How

   Chrome47.0.2526.106
   WINDOWS8.1x64

   frankThe 2017-03-03 good tidings
   reply

7. 

   Um half meng state read this big, first love the author half a second, um and then read only understand the meaning is, wechat pit wall ==

   OPERA44.0.2510.73
   WINDOWS7x64

   LCThe 2017-02-28 13:53
   reply

8. 

   The same problem is encountered, but due to service problems, the data cannot be returned directly and then processed asynchronously. Program execution will need about 2 to 4 s, repeat submit the case is not appear, every time will appear occasionally, however, use with mobile phones, to request the same network environment, really hurt, judge program inside If there is no database operations, but this a few times request time interval is too short, and concurrency issues, So this if else judgment doesn’t work, so what do we do

   Chrome55.0.2883.87x64
   WINDOWS7x64

   kakaThe 2017-01-17 roar,
   reply

   • 

     Would asynchronous Ajax be better?

     Chrome58.0.3029.110x64
     WINDOWS7x64

     ccfishThe 2017-06-29 came
     reply

     • 

       It doesn’t matter if it’s asynchronous Ajax.

       Chrome61.0.3143.0x64
       WINDOWS10x64

       Wooden fishThe 2017-06-30 therefore
       reply

9. 

   We met once. We worked it out

   Sogou
   WINDOWS7x64

   Jack BauerThe 2016-10-27 o
   reply

   • 

     How do you solve it, please advise, our project team also encountered such a problem, thank you!

     Firefox34.0
     WINDOWS7

     ha88haThe 2017-03-21 so
     reply

10. 

    I also have this problem because the method in my Ajax background synchronizes the 4 interfaces called and enters the library, which takes more than 7 seconds. At first I thought it was a procedural problem, but it took me most of the day… Either asynchro or de-repetition is useless because the current Ajax call will immediately jump to the second page to display the newly loaded data, and then jump to the second page to return an error. . The solution is to do the background judgment, if the data exists, do not insert, tube TM wechat tune how many times.

    Chrome53.0.2785.101x64
    WINDOWS10x64

    rootThe 2016-10-13″
    reply

11. 

    Task queue + status polling?

    Chrome Mobile53.0.2785.97
    MIUI
    MIMAX

    openggThe 2016-09-13 13:39
    reply

    • 

      You got a new phone…

      Chrome55.0.2858.0x64
      WINDOWS10x64

      Wooden fishThe 2016-09-13 21:43
      reply

      • 

        .

        QQ Browser9.5.9635.400
        WINDOWS10x64

        tungseThe 2016-12-19″
        reply

    • 

      PHP can be done

      Chrome58.0.3029.110
      MAC OS10.12.5

      ghostThe 2017-05-26 15:42
      reply

12. 

    Your website and software are considered malicious by Microsoft’s antivirus software and Edge. SmartScreen does not allow all the software on your site. In the company and at home with win10 access are like this, trouble check.

    EDGE14.14393x64
    WINDOWS10x64

    TAnThe 2016-09-10 10:06
    reply

    • 

      I haven’t come across such a situation, so I can’t deal with it.

      Chrome55.0.2854.2x64
      WINDOWS10x64

      Wooden fishThe 2016-09-11 no
      reply

13. 

    Hi. Today, I encountered a problem on wechat. When the user submitted the form, Ajax request was used to initiate. The request was sent, but the form was not saved successfully. There was nothing wrong with the test environment. In a production environment, as you mentioned, Iphone is fine. That will happen with Android

    Chrome52.0.2743.116
    WINDOWS7x64

    MandosBorThe 2016-09-05 now
    reply

    • 

      The additional reason is that the data the user fills in is not passed to the background via Ajax, which is the problem with Ajax POST requests. The current solution is get

      Chrome52.0.2743.116
      WINDOWS7x64

      MandosBorThe 2016-09-07″
      reply

      • 

        POST No problem… Try debugging with wechat development tools

        Chrome55.0.2851.0x64
        WINDOWS10x64

        Wooden fishThe 2016-09-07 18:08
        reply

        • 

          No, no, no. There is no problem with the debugging of wechat development tools. Oddly enough, the tests were fine until the production environment was released and Android started to have this problem in large numbers. But!! Oddly enough, requests for other pages are perfectly fine. It’s a meltdown.

          Chrome52.0.2743.116
          WINDOWS7x64

          MandosBorThe 2016-09-08″
          reply

          • 

            Only one page is down? Ah-ha. It’s annoying to have a problem on the line. Wechat has a bad review of this embedded browser.

            Chrome55.0.2853.0x64
            WINDOWS10x64

            Wooden fishThe 2016-09-09 11:59

        • 

          Yi. There’s no reply button on the last one. This browser is really… A long story ！！！！！！

          Chrome52.0.2743.116
          WINDOWS7x64

          MandosBorThe 2016-09-09 returned from
          reply

      • 

        My get doesn’t work either… It’s been a long day.

        Chrome51.0.2704.106
        WINDOWS10x64

        cyaeoThe 2016-11-23″
        reply

14. 

    For me, starting from Linux, I start with tcpdump first, so that I can find that most of the pages you browse on wechat are proxy, and the pages you see are not even files on your own server. Sometimes when you use tcpdump to capture packets, you may find that your own server does not receive a corresponding request when opening the page. With Ajax, there’s no way to tell where your requests are going. And since this is a client-level hijacking, HTTPS is useless. As the mobile version of IE6 in the era of smart phones, wechat has too many pits. You know, this test is also a blind cat, the test is also a fool, Debug is so confused.

    Chrome52.0.2743.116x64
    WINDOWS7x64

    Shi Ying lanternsThe 2016-08-31 cuthah
    reply

    • 

      It’s really a pit. I recently did some development related to wechat and found that I had no contact with it before. Who would have thought that the problem is actually wechat pot ah, really speechless.

      Chrome55.0.2844.0x64
      WINDOWS10x64

      Wooden fishThe 2016-08-31 23:48
      reply

15. 

    So one of the phones with this problem is the Mi 3?

    Chrome52.0.2743.116x64
    WINDOWS7x64

    Micro blue2016-08-16 moreover,
    reply

    • 

      There is. This is the mechanism of wechat, and the specific model should have no relationship.

      Chrome54.0.2829.0x64
      WINDOWS10x64

      Wooden fishIn the 2016-08-16 s the same
      reply

16. 

    Is there any other solution to this problem

    Chrome51.0.2704.106
    WINDOWS10x64

    lanrainThe 2016-07-19 thus
    reply

17. 

    This pit had very early ah, can only say building Lord hind know hind feel…

    Here are two userAgents: Mozilla/5.0 (Linux; U; Android 4.4.2. zh-cn; Gt-i9500 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko)Version/4.0 MQQBrowser/5.0 QQ-Manager Mobile Safari/537.36

    Mozilla / 5.0 (iPhone; CPU iPhone OS 8_1_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML like Gecko) (Engine, Like URL) Mobile/12B440 MicroMessenger/6.0.1 NetType/3G+

    I think this TMD must be wechat server disguised the above two userAgents to pull the user access to the page for monitoring

    Chrome51.0.2704.103
    WINDOWS10x64

    A small stepThe 2016-07-08 09:43
    reply

    • 

      The embedded page of wechat has not been done before. What’s wrong with these UAs? I don’t see anything wrong.

      Chrome54.0.2790.0x64
      WINDOWS10x64

      Wooden fishThe 2016-07-08 12:08
      reply

    • 

      Encounter same problem, how does this problem break excuse me

      Chrome47.0.2526.106
      WINDOWS8.1x64

      frankThe 2017-03-03 also
      reply

18. 

    Higher position!

    Firefox49.0
    WINDOWS7x64

    A passer-byThe 2016-07-08 09:40
    reply

19. 

    Big fish into Tencent?

    QQ Browser9.4.8309.400
    WINDOWS10x64

    tanranranThe 2016-07-07 23:48
    reply

    • 

      Don’t.

      Chrome54.0.2790.0x64
      WINDOWS10x64

      Wooden fishThe 2016-07-08 02:46
      reply

      • 

        Love fish three seconds, 3:00 a.m. at the code

        Chrome45.0.2454.101
        WINDOWS7

        duyuan2The 2016-07-08 09:29
        reply