1500743 - weixin.qq.com (The Official website of WeChat) can not be opened, but Chrome and Safari can

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[kingboy9525]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

I open the weixin.qq.com with Firefox/Chrome/Safari. They are all the newest released version.

Btw, the website is the official website of WeChat. WeChat is the most popular instant-messager app in China.

 


Actual results:

The website can not be opened with Firefox, but Chrome and Safari can.

I have used Firefox's safe mode and stoped all my plugins and addons.

And I also called my friend who had tried the same operation(also use the 62.0.3). But it's also not functioning properly.


Expected results:

weixin.qq.com can be opened normally with Firefox.

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Interesting, i can reproduce the issue too.
Daniel, I think you like this kind of bug. Do you have a clue?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Daniel^2, I have been told that it might be http2 related. If you have an idea!

Comment 3

[Julien Wajsberg [:julienw]]

Attachment: full network logging for 1 request

Comment 4

[Calixte Denizet (:calixte)]

In using mozregression, I got this pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ced1402861b8&tochange=cef590a6f946

Comment 5

[Alice0775 White]

(In reply to Calixte Denizet (:calixte) from comment #4)
> In using mozregression, I got this pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=ced1402861b8&tochange=cef590a6f946

Suspect: bug 1097320

Comment 6

[u408661]

So this is because the server is sending us a GOAWAY frame with the error PROTOCOL_ERROR - indicating that it thinks we spoke broken http/2 in... some way or another. This is immediately after us sending all the things we usually do when we open an http/2 connection - the required "magic", our SETTINGS frame, a WINDOW_UPDATE for the session, and a bunch of nodes for our priority dependency tree, followed by the very first request (which includes the HEADERS+PRIORITY as well as a WINDOW_UPDATE frame for the stream - there is no request body, so there are no DATA frames).

After that, we receive the server's SETTINGS, plus an ACK for our SETTINGS, and we send out an ACK for their SETTINGS (as required).

This is exactly what we do with every other h2 server in the world, and no others abruptly hang up on us claiming we're broken. Without more data from the server side of things (specifically what it thinks we did wrong - PROTOCOL_ERROR is kind of a catchall), I can't get any farther figuring out what potentially went wrong. However, I suspect this is a server-side issue anyway, given that no one else complains about us.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Nicholas, don't you think that we should at least show an error message/warning in Firefox?

Comment 8

[u408661]

Bumping this over to tech evangelism, so they can reach out to wechat to help figure out what's going wrong here. I'm more than happy to help with technical details, if needed.

Comment 9

[u408661]

(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Nicholas, don't you think that we should at least show an error
> message/warning in Firefox?

That's bug 1050329 :)

Comment 10

[u408661]

Argh, I said I was moving the bug, then the comment collision happened, and it didn't get moved. Really, truly, I'm moving the bug this time. (See comment 8)

Comment 11

[Adam Stevenson [:adamopenweb]]

Filed a bug at:
https://help.wechat.com/oshelpcenter

Attempted email contact to these addresses:
https://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_open/contact

Also Chris Arnold is reaching out to contacts there.

Comment 12

[u408661]

Another point here, that I've uncovered with a hunch and a little more digging: at least part of the issue is that we send "te: trailers" as a header on our requests in http/2. That's perfectly legal, but any other "te" header would be illegal. If I make a build that does not send "te: trailers", then things get a bit farther (though they still fail) - the server doesn't send a GOAWAY frame (good), but the load never completes (bad).

So, right now, there is one server-side bug (failure to accept "te: trailers" as legal), and one bug of unknown source (load never completes).

I'm digging in on the incomplete load right now, to see if I can figure out more there.

Comment 13

[u408661]

OK, I've looked at the incomplete load, and that also appears to be a server-side issue. Once we send our request, the server just never responds (no traffic at all on the net, with the exception of the TCP-level ACK of our the packets that include our http/2 request).

The only thing that appears significantly different between us and chrome is that chrome does not send a WINDOW_UPDATE http/2 frame in the same TCP packet as the HEADERS http/2 frame, while we do. Chrome doesn't send a WINDOW_UPDATE for the stream at all, in fact. That's, again, totally legal for us to do, but it's also my best guess as to what is messing up the server in the second bug I mentioned in comment 12 (since it's the only appreciable difference between us & chrome that isn't also present in http/1.1).

Comment 14

[Daniel Stenberg [:bagder]]

Just an additional data-point that I happened to notice.

If I try this page with curl (which gets content back over h2) there's a very interesting little detail in its verbose details:

$ curl weixin.qq.com -vL -o /dev/null
...
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!

That's a lot of streams! =)

Comment 15

[u408661]

(In reply to Daniel Stenberg [:bagder] from comment #14)
> Just an additional data-point that I happened to notice.
> 
> If I try this page with curl (which gets content back over h2) there's a
> very interesting little detail in its verbose details:
> 
> $ curl weixin.qq.com -vL -o /dev/null
> ...
> * Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
> 
> That's a lot of streams! =)

Interesting, I assume that's coming from wechat (and not from curl)? I ask, because I note that wechat does not send *any* actual settings values to either firefox or chrome, just an empty SETTINGS frame to satisfy the server preamble requirement from 7540.

Comment 16

[u408661]

Ooooh. One last thing I noticed (which caused a few people problems during the ietf process, but was explicitly agreed upon as ok). The first stream ID firefox uses is somewhere between 0x3 and 0xF (depending on if the priority tree is enabled). However, chrome (and curl, and, I assume, safari) all use 0x1 as the first stream id. I wouldn't be surprised if wechat's server is waiting for stream 0x1 to come in (which it never does, as firefox intentionally never uses that stream id).

Comment 17

[Adam Stevenson [:adamopenweb]]

Their policy team responded:
"I have forwarded the report to the appropriate member of our team to diagnose and repair the situation"

Comment 18

[Mike Taylor [:miketaylr]]

(In reply to Nicholas Hurley [:nwgh][:hurley] (he/him) from comment #16)
> Ooooh. One last thing I noticed (which caused a few people problems during
> the ietf process, but was explicitly agreed upon as ok). The first stream ID
> firefox uses is somewhere between 0x3 and 0xF (depending on if the priority
> tree is enabled). However, chrome (and curl, and, I assume, safari) all use
> 0x1 as the first stream id. I wouldn't be surprised if wechat's server is
> waiting for stream 0x1 to come in (which it never does, as firefox
> intentionally never uses that stream id).

Nicholas, how hard would it be to test sending 0x1, to see if it makes a difference here?

Comment 19

[u408661]

I can do a quick local build with the changed stream id to check. Leaving ni? until I have an answer.

Comment 20

[u408661]

Unfortunately, it would seem my idea in comment 16 was incorrect - changing our first stream id to 0x1 does not make any difference.

Comment 21

[Mike Taylor [:miketaylr]]

thanks for checking!

Comment 22

[Adam Stevenson [:adamopenweb]]

Following up with the policy team to see if we can get an update.

Comment 23

[Adam Stevenson [:adamopenweb]]

We've been put in contact with the relevant engineers. Added :nwgh and :stpeter to the email chain.

Comment 24

[Adam Stevenson [:adamopenweb]]

They have acknowledged the issue and committed to fixing it. Asking if they can provide an estimate of when it will be fixed.

Comment 25

[Adam Stevenson [:adamopenweb]]

They are looking to have the issue addressed sometime this month.

Comment 26

[YF (Yang)]

bug 1398654.

Comment 27

[yxu]

It seems that WeChat has solved this problem.

Comment 28

[Adam Stevenson [:adamopenweb]]

Yes, they responded that they have deployed the fix. Thanks everyone!