1057813 - [Captive Portal] We should not cache the result of http://detectportal.firefox.com

Status: RESOLVED FIXED

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Julien Wajsberg [:julienw]]

STR (will be difficult to reproduce in QA conditions):
1. use a WiFi network with captive portal
=> Firefox OS correctly detects it is a captive portal and display a notification
2. tap the "portal detected" notification
=> Firefox OS Browser correctly redirects to the captive portal's login
3. login to the portal
=> everything works fine
=> the browser shows SUCCESS
4. some days later, we need to login on the portal again.
=> Firefox OS correctly detects it is a captive portal and display a notification
5. tap the "portal detected" notification
=> Firefox OS Browser shows "success" directly without logging in to the portal (KO)
=> Internet still doesn't work on the phone.


I think the issue is that the server http://detectportal.firefox.com sends no Expires header; as a result, we cache the result using an heuristic.
We should either
* add this server name to the heuristic logic (I would not recommend this).
* or send a Expires header with "-1" as value (easiest and most future proof if the server name changes for some reason).

[Blocking Requested - why for this release]:
The captive portal feature is broken if we stay some days in the same place. Moreover it should be really easy to fix on the server side, so no code is involved.

Comment 1

[Julien Wajsberg [:julienw]]

(note: I've put this bug in the Gaia component but since it's server side it should probably be in another component).

Comment 2

[Jason Smith [:jsmith]]

William - Could you see if you can reproduce this?

Comment 3

[William Hsu [:whsu]]

(In reply to Julien Wajsberg [:julienw] (PTO 08/19 -> 09/15; contact schung for SMS matters) from comment #0)
> STR (will be difficult to reproduce in QA conditions):

Thanks Julien and Jason.
QA can adjust system time and date to do the test.
But, if we clean browser's cache via browser setting page, it may solve this problem, right?

> [Blocking Requested - why for this release]:
> The captive portal feature is broken if we stay some days in the same place.
> Moreover it should be really easy to fix on the server side, so no code is
> involved.

By the way, this seems to cause by inappropriate server response.
Could we change the component to the appropriate one?

*** Keep NI?:whsu to reproduce it ***

Comment 4

[bhavana bajaj [:bajaj]]

NI, tim to get his input here on blocking this. Tim, i remember you may have helped with captive portal at one point, can you weigh in here or re-direct as needed ?

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Vincent, would you be able to ask your team to tweak Necko for this? Please change the product/component.

I recommend we block this bug for 2.1 on the basis of user annoyance, but this should not be considered as a regression.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Julien Wajsberg [:julienw] (PTO 08/19 -> 09/15; contact schung for SMS matters) from comment #1)
> (note: I've put this bug in the Gaia component but since it's server side it
> should probably be in another component).

Wait, I am a bit confused. Julien, what do you recommend we do on the Gaia side, or the client side in general? I just what to figure out the item to do falls into Gecko or Gaia. I don't read that in the "We should..." part of comment 0.

Comment 7

[Vincent Chang[:vchang][changyihsin]]

I think Chuck has a solution to fix this in gecko side, not sure if it's too hacky or not.

Comment 8

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

We could make every request URL different by adding dummy postfix timestamp, like http://detectportal.firefox.com?1409127052981, so it won't hit cache.

Comment 9

[William Hsu [:whsu]]

I cannot find available captive portal WIFI to reproduce this problem recently.

But, Chuck seems to know the solution.
Remove the NI.

Comment 10

[bhavana bajaj [:bajaj]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5)
> Vincent, would you be able to ask your team to tweak Necko for this? Please
> change the product/component.
> 
> I recommend we block this bug for 2.1 on the basis of user annoyance, but
> this should not be considered as a regression.

Given this has been around for long and not a recent regression, we can fix this in 2.1 given we want to avoid any un-wanted changes in 2.0 at this point. Lets prioritize this for 2.1

Comment 11

[Julien Wajsberg [:julienw]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> (In reply to Julien Wajsberg [:julienw] (PTO 08/19 -> 09/15; contact schung
> for SMS matters) from comment #1)
> > (note: I've put this bug in the Gaia component but since it's server side it
> > should probably be in another component).
> 
> Wait, I am a bit confused. Julien, what do you recommend we do on the Gaia
> side, or the client side in general? I just what to figure out the item to
> do falls into Gecko or Gaia. I don't read that in the "We should..." part of
> comment 0.

My idea was to fix it on the server side, and not do any change in gecko/gaia at all.
We can simply send an Expires header with "-1" as value, and then Gecko will always revalidate the data without caching it.

This is the simplest solution, and it does not even need blocking because it's server side.

Note that I got the issue on other hotspots too: the "SUCCESS" string was shown in the Browser even than I haven't log in yet. Reloading the page (forcing the revalidation then) made the login appear.

The feature is broken, so please, let's fix it server side. I could recover because I know how this works, a normal user won't recover and will say Firefox OS is broken, which is obviously true.

Who handles the detectportal.firefox.com http server?

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I see. This is not a FxOS bug then.

The prod/comp should be that of bug 842953.

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Needinfo'ing Jeremy to get more attention. 

Jeremy, we need to set the file hosted on detectportal.firefox.com to always expire. Would you be able to help out? Thanks!

Comment 15

[Jeremy Orem [:oremj]]

I've added:
Cache-Control: "no-store, no-cache, must-revalidate, max-age=0"


Will that do?

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I think so, but Gecko devs can confirm.

Comment 17

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

I think it should work.
Julien, can you help to test again in real environment?

Comment 18

[Julien Wajsberg [:julienw]]

well, it seemed to work better lately :) I expected it to fail and it worked !

So I think it's RESOLVED FIXED :)