bryanc
yeah it's a bit confusing, the documents are not really clear about it. Here is the summary for you:
since day 1, Aruba used a HTTP 302 redirect mechanism, as do most captive portals. The sequence being like this
a) user browses to cnn.com
b) dns happs, gets IP 1.2.3.4 and sends tcp syn to 1.2.3.4:80
c) captive portal acl picks it up, dest nats it to controller
d) controller spoofs the other half of the tcp connection from 1.2.3.4, the browser sets up a tcp connect and does HTTP GET / (or other page)
e) controller responds with a 302 redirect to the 'login page' and appends all the captive portal window dressing (macaddr and friends)
f) client then follows the 302 redirect which causes the actual captive portal login page to be generated and sent to the client. In the case of the controller, and especially in the case of https, this is real "work"
All was well until smartphones turned up with background apps doing everything in the background, which caused the httpd on the controller to get pounded all day long, setting up connections, sending 302 redirects that when followed, returned the whole login page to some app that only cared about polling some API endpoint for the weather forecast etc....
The solution to this was, in short, to send HTML back containing a <meta http-equiv='refresh' location='somewhere'> rather than setting the Location in the HTTP header.
The reason being that background apps generally don't decode HTML and thus they don't follow the 'refresh' and don't end up putting any further load on the controller beyond that first packet.
You can demonstrate this to yourself using wireshark and your webbrowser. Below demo is using curl because it's easier to copy/paste here (captive portal set to controller landing page, protocol-http enabled)
>> A) Enable bypass captive portal landing page false (default)
$ curl --verbose http://cnn.com
* Trying 151.101.1.67...
> GET / HTTP/1.1
> Host: cnn.com
> User-Agent: curl/7.56.1
> Accept: */*
< HTTP/1.1 200 Ok
< Date: Mon, 15 Jan 2018 14:22:49 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< X-UA-Compatible: IE=edge;IE=11;IE=10;IE=9
< Expires: 0
< Content-Length: 134
< Connection: close
< Content-Type: text/html
<
<html>
<head>
<meta http-equiv='refresh' content='1; url=http://cnn.com/&arubalp=c9669565-d7df-4f12-873e-70baf57a3a'>
</head>
</html>
>> B) Enable bypass captive portal landing page true
$ curl --verbose http://cnn.com
* Trying 151.101.1.67...
> GET / HTTP/1.1
< HTTP/1.1 302 Temporarily Moved
< Date: Mon, 15 Jan 2018 14:01:12 GMT
* Server Apache is not blacklisted
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< X-UA-Compatible: IE=edge;IE=11;IE=10;IE=9
< Location: http://192.168.1.123/cgi-bin/login?cmd=login&mac=10:00:02:3f:21:ea&ip=192.168.1.52&essid=cp%2Dcp&apname=apXYZ&apgroup=blah&url=http%3A%2F%2Fcnn%2Ecom%2F
In the first case, the default, you can see the controller sending back
<meta http-equiv='refresh' content='1; url=http://cnn.com/&arubalp=c9669565-d7df-4f12-873e-70baf57a3a'>
which in itself, once queried, will return a 302 redirect that looks like item B) above, this acting as a bit of a double blind (arubalp == aruba landing page).
The amount of CPU saved here is significant, certainly you should leave it set to 'false' in 6.4.x which means "use the <meta> method"
Side note, if you're having high httpd cpu on M3, you can also review a few things like whether you can do with out https, or better still run the page in http, and just set the action in the username/password form to be https.
hth.