- From: David Morris <dwm@xpasc.com>
- Date: Thu, 15 Mar 2007 14:57:28 -0800 (PST)
- cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, 15 Mar 2007, Mark Nottingham wrote: > Good question. Most of the ones I've seen recently redirect initially > to a non-HTTPS site to avoid the certificate mismatch popup. In my experience, the hotels, public access wi-fi, etc. just block outbound traffic (except DNS) until you follow the rules and attempt to bring up an http: port 80 web page. The places I've been were mostly free .... they just wanted T&C agreement. I'd prefer to see more design with more than ad-hoc attention to real use cases. Just offering a new status code is probably an incomplete solution with the result there will be badly flawed implementation and no real improvement in end user experience. For example, my frustration isn't with the interruption, it is with the loss of navigation. When the authentication is finished, I must figure out where I was going which isn't always easy and may be impossible because I didn't know in the first place. I'd like a pair of status codes ... with a push down property: a. 3xx ... we interrupt your program for this important announcement b. .. some interaction ... like authentication c. 3yy ... we now return to your regular scheduled program The devil is in the details, but 'a' would include a redirect URL ... might include a new browser window/tab/ colored frame, etc. to visually inform the user of the interruption. 'c' would mean tear down the special visuals AND resubmit the request which was interrupted in 'a'. Special purpose clients could recognize 'a' and at least not give erroneous results, perhaps tell the user to open their browser, OR even just open a browser instance... Dave Morris
Received on Thursday, 15 March 2007 22:57:36 UTC