Last modified: 2014-07-05 21:48:02 UTC
Whenever user has forceHTTPS cookie, any request that comes in via HTTP is automatically redirected to HTTPS. This behaviour is ok for most of the usecases, but it causes countless grievances in the zero-land for the following scenario: User logs in (or obtains forceHTTPS cookie via some other means) while browsing *.wikipedia.org on WiFi or mobile network. At some point, they discover that their carrier offers wikipedia for free via *.zero.wikipedia.org. They try to navigate there, only to discover that they get an error screen due to using HTTPS (which is not supported by zero most of the time). They report it to the carrier, carrier, complains to us, and we have to explain to them that the only way for the user to use us ever since they got tainted by the "forceHTTPS" is to clear their browser's cookie storage. In order to prevent the unnesesary grievance by many users (and we have heard a lot of this scenario), Zero extension needs to intercept http->https redirect. This redirect happens before most of the code, hence a new hook is needed, as implemented in Change-Id: If04c83066c5d4. The redirect will be canceled only for the case of valid traffic from Zero partner , exclusivelly to *.zero. subdomain. Please note that we are not breaking existing functionality here since zero hasn't had a valid SSL certificate until a week ago, and regardless, we do not currently support authentication or editing via zero subdomain.
Two pending patches: Core: If04c83066c5d4 Zero: Ia8b620282bb01
(In reply to Yuri Astrakhan from comment #1) > Two pending patches: > Core: If04c83066c5d4 > Zero: Ia8b620282bb01 Yuri: Both merged. What's left here?
