1335234 - Some sites with redirects cannot be loaded

Status: RESOLVED FIXED

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

Description

[Matt Wobensmith [:mwobensmith][:matt:]]

A routine run of TLS Canary found four sites that can no longer load in Fx52 and above. An error page is displayed, indicating "The page isn’t redirecting properly."

Please note that this issue affects non-secure versions of these sites as well, so probably unrelated to TLS.

URI, rank
www.messe.de, 197653	
www.hannovermesse.de, 203429	
www.domotex.de, 405086	
ihealthtran.com, 999898	

This issue exists in Fx52.0b1, Fx53.0a2 and Fx54.0a1. The window of regression is between 2017-01-16 and 2017-01-27.

Comment 1

[Honza Bambas (:mayhemer)]

Can't reproduce in a clean profile with Fx52.  Are there any more data like addons correlations or something?

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Hmmmm, just tried Fx52.0b2 and today's Fx54.0a2 nightly, and you are right, not able to reproduce there either.

Baffling. I will investigate further.

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

s/Fx54.0a2/Fx54.0a1

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

OK, new steps. This seems to involve HTTPS after all.

1. Open Fx52.0b2.
2. Create clean profile.
3. https://ihealthtran.com

Results:
"The page isn’t redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies."

Expected:
Successful redirect.

Note that this issue doesn't happen if your first attempt to hit the site is via HTTP and not HTTPS.

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

Just tried my new steps in Fx51 and it's a problem there, too, so not a regression (and possibly not a Fx bug).

Still trying to understand why my regression testing picked it up now and not before. 

More investigation underway.

Comment 6

[Matt Wobensmith [:mwobensmith][:matt:]]

Once again, but with a different URI than comment 4.

1. Open Fx52.0b2.
2. Create clean profile.
3. https://www.messe.de

Result: 
Error page

Expected:
Page loads as it does in Fx51 release.

Comment 7

[Honza Bambas (:mayhemer)]

Chrome behaves the same way.  IE loads the page.

Comment 8

[Honza Bambas (:mayhemer)]

This could be a cookie problem.  The first response (secured) sends:

Set-Cookie: JSESSIONID=87045B885056BF021CF04215A49ADDA4; Path=/; Secure; HttpOnly
SRV=b04|WJISy; path=/

Every other response sends (the value is changing every time):

Set-Cookie: JSESSIONID=BE1C12C836D3592358442AC7A4FEA4F8; Path=/; HttpOnly

But we never send the JSESSIONID cookie back.  


IE does send it with the request to http://www.messe.de/home: 

Cookie: JSESSIONID=87322BFA91DEB1CA07A7D6C12F001DC7; SRV=b07|WJIZM.



Marking as unconfirmed, since Chrome (release) behaves the same way as we do.  I'm no cookie expert, so someone has to decide who is behaving correctly.  Probably Ehsan?

Comment 9

[(no longer active)]

As far as I can tell, we are doing the right thing.  It's interesting that both wget and curl are broken. :(  For example:

$ curl -vL https://www.messe.de 2>&1 | head -50
* Rebuilt URL to: https://www.messe.de/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 193.22.29.105...
* TCP_NODELAY set
* Connected to www.messe.de (193.22.29.105) port 443 (#0)
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: www.messe.de
* Server certificate: TeleSec ServerPass CA 2
* Server certificate: Baltimore CyberTrust Root
> GET / HTTP/1.1
> Host: www.messe.de
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: nginx
< Date: Wed, 01 Feb 2017 18:30:46 GMT
< Content-Length: 0
< Connection: keep-alive
< Set-Cookie: JSESSIONID=0673F1EED3DBB7B1169322D090857781; Path=/; Secure; HttpOnly
< Location: http://www.messe.de/
< Set-Cookie: SRV=b04|WJIpW; path=/
<
* Curl_http_done: called premature == 0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host www.messe.de left intact
* Issue another request to this URL: 'http://www.messe.de/'
*   Trying 193.22.29.105...
* TCP_NODELAY set
* Connected to www.messe.de (193.22.29.105) port 80 (#1)
> GET / HTTP/1.1
> Host: www.messe.de
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 01 Feb 2017 18:30:46 GMT
< Server: Apache
< Set-Cookie: JSESSIONID=85C302F052E6CB7380390901506D0E78; Path=/; HttpOnly
< Transfer-Encoding: chunked
< Content-Type: text/html;charset=UTF-8
< Set-Cookie: SRV=b15|WJIpW; path=/
< Cache-control: private
<
{ [4071 bytes data]
<!DOCTYPE html>
<!--[if lt IE 7]>              <html prefix="og: http://ogp.me/ns#" lang="de" class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]--><!--[if IE 7]>                 <html prefix="og: http://ogp.me/ns#" lang="de" class="no-js lt-ie9 lt-ie8"> <![endif]--><!--[if IE 8]>                 <html prefix="og: http://ogp.me/ns#" lang="de" class="no-js lt-ie9"> <![endif]--><!--[if IE 9]>                 <html prefix="og: http://ogp.me/ns#" lang="de" class="no-js ie9 can-maxwidth can-cssclip"> <![endif]--><!--[if gt IE 9]><!-->   <html prefix="og: http://ogp.me/ns#" lang="de" class="no-js can-maxwidth can-cssclip"> <!--<![endif]--><head>
	<meta charset="utf-8" />
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

We correctly refuse to send the secure cookie after the redirect because, well, the cookie is secure.  :-)  <http://searchfox.org/mozilla-central/rev/e95e4ed8b5229a29dacc32c0b90968df5e7a6ff3/netwerk/cookie/nsCookieService.cpp#3280>

However if this redirect worked in 51, we should figure what actually broke it, I doubt the cookies are relevant.

Matt, can you please use mozregression to figure out which commit broke this?

Comment 10

[(no longer active)]

One thing that is suspect here is this:

We start fetching https://www.messe.de.  That serves us a secure JSESSIONID and a normal SRV cookie.  Then we follow the redirect to http://www.messe.de/ sending the SRV cookie, which serves us a *non-secure* JSESSIONID cookie.  Then we follow the redirect to http://www.messe.de/home but this time we also only send the SRV cookie and not JSESSIONID.  That's the bug and I suspect is the cause behind the HTTP infinite redirection because the server is redirecting all requests without JSESSIONID.  But I'm not sure what has broken it.

Comment 11

[(no longer active)]

(Also be careful how much you trust the netmonitor, see bug 1335837.  The cookies view seems to be unaffected.)

Comment 12

[Alice0775 White]

(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #6)
> Once again, but with a different URI than comment 4.
> 
> 1. Open Fx52.0b2.
> 2. Create clean profile.
> 3. https://www.messe.de
> 
> Result: 
> Error page
> 
> Expected:
> Page loads as it does in Fx51 release.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=804bcd698ce569e5b83852358619f1453550f20e&tochange=b86094c4eafc59ef953655fa6996ca242bd55320

Regressed by:  Bug 976073

Comment 13

[François Marier [:francois]]

CCing dveditz who recently changed the behaviour of secure cookies. I think this breakage is intended.

Comment 14

[(no longer active)]

Yeah.  Let's walk through what's happening:

>(In reply to :Ehsan Akhgari from comment #10)
> One thing that is suspect here is this:
> 
> We start fetching https://www.messe.de.  That serves us a secure JSESSIONID
> and a normal SRV cookie.

OK, at this point we have a secure JSESSIONID cookie.  Good.

> Then we follow the redirect to
> http://www.messe.de/ sending the SRV cookie, which serves us a *non-secure*
> JSESSIONID cookie.

The cookie we send here is correct.  The non-secure JSESSIONID cookie should be *ignored* per bug 976073, not changing anything in the cookie store.

> Then we follow the redirect to http://www.messe.de/home
> but this time we also only send the SRV cookie and not JSESSIONID.

This is because there is no non-secure JSESSIONID cookie.

Moving this to Tech Evangelism.  We need to contact these sites and ask them to fix things on their end.

Comment 15

[Matt Wobensmith [:mwobensmith][:matt:]]

Sorry, was in the middle of finding the regression window, but Alice0775 White beat me to it.

Still baffled as to why the canary didn't detect these sites until now. I will run mozregression next time this happens to improve my process, so that I don't waste anyone's time.

Comment 16

[Karl Dubost💡 :karlcow]

for https://www.messe.de it redirects to https://www.messe.de/home