W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: I-D Action:draft-nottingham-http-portal-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 19 Aug 2010 15:23:36 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <589D714E-8A28-44BF-9CC0-B8A08904F273@mnot.net>
To: Dan Winship <dan.winship@gmail.com>
On 19/08/2010, at 12:15 AM, Dan Winship wrote:

> On 08/05/2010 02:11 AM, Mark Nottingham wrote:
>> Feedback appreciated. My intent is to engage with folks who are
>> using captive portals (have already made some small headway
>> there) and register a new status code if a) feedback here and
>> there is good and b) they indicate willingness to implement.
> 
> It really seems like this ought to be handled by a DHCP option saying
> "the IP address I just assigned you won't be usable until you visit the
> following URL". (Since, AFAIK normally the DHCP server is part of the
> portal as well.)

Agreed, but see below.

> from the draft:
>>   Overall, there may also be an interesting discussion to be had about
>>   improving network access methods to the point where a user interface
>>   can be presented for the same purposes, without resorting to
>>   intercepting HTTP traffic.  However, since such a mechanism would by
>>   necessity require modifying the network stack and operating system of
>>   the client, this memo takes a more modest approach.
> 
> It's true that on desktop platforms the browsers are faster-moving than
> the core OS, but I don't think that's true for mobile devices.
> 
> And if we're getting the portal makers to make changes now anyway, it
> might be more productive to get them to make two changes (an HTTP-only
> fix and a whole-network-stack fix) at once. It might take a while before
> Windows, eg, got updated to support the whole-network-stack fix, but
> when they did, the portals would already be ready for them.


It's not the browser that you have to worry about, it's all of the various feed readers, software that uses HTTP for updates, etc. 

For that matter, it's really all applications that use the network; you'd need some sort of strategy for telling them that the network isn't available due to authentication reasons (unless you just make it appear that the network is down, except for browsers going to the login portal).

As you can probably tell, I'm not at all against creating such a DHCP option, but I also think it's a longer-term and more difficult thing to get right. If you (or anyone else) wants to come up with a draft exploring the options there, please do so!

Cheers,



--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 19 August 2010 05:24:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:24 GMT