Subject: New Status Code -- 2xx Greedy Hotel?

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Mar 2007 13:48:17 +0000

After being in hotels for a few weeks, I'm starting to wonder whether  
a new 2xx HTTP status code could be defined whose semantic is "This  
isn't what you asked for, but here's some information about how to  
get network access so you can eventually get it."

2xx so that browsers will display it. AFAICT, they do; or at least,  
Safari and Firefox do (see <http://www.mnot.net/test/222.asis>). IE?  
4xx might be more appropriate, but I despair of "friendly" error  
messages. (thought they could be padded, I suppose).

A new status code so that feed aggregators, automated clients, etc.  
can differentiate what they asked for from your hotel / conference  
centre / etc. asking for cash in order to get network access, and not  
get horribly messed up as a result.

It would also be useful in those cases where you get redirected  
somewhere to login and get a cookie for authentication; e.g., Yahoo!,  
Google, Amazon, etc. Same situation, but slightly different use case.

Thoughts?

--
Mark Nottingham     http://www.mnot.net/

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 15 Mar 2007 14:55:20 +0100

I wonder if a specific redirect code wouldn't be better.
-- 
Thomas Roessler, W3C  <[email-masked]>

On 2007-03-15 13:48:17 +0000, Mark Nottingham wrote:
> From: Mark Nottingham <[email-masked]>
> To: "[email-masked] Group" <[email-masked]>
> Date: Thu, 15 Mar 2007 13:48:17 +0000
> Subject: New Status Code -- 2xx Greedy Hotel?
> List-Id: <ietf-http-wg.w3.org>
> X-Archived-At: http://www.w3.org/mid/[email-masked]
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 

> After being in hotels for a few weeks, I'm starting to wonder whether a new 2xx HTTP status 
> code could be defined whose semantic is "This isn't what you asked for, but here's some 
> information about how to get network access so you can eventually get it."

> 2xx so that browsers will display it. AFAICT, they do; or at least, Safari and Firefox do (see 
> <http://www.mnot.net/test/222.asis>). IE? 4xx might be more appropriate, but I despair of 
> "friendly" error messages. (thought they could be padded, I suppose).

> A new status code so that feed aggregators, automated clients, etc. can differentiate what they 
> asked for from your hotel / conference centre / etc. asking for cash in order to get network 
> access, and not get horribly messed up as a result.

> It would also be useful in those cases where you get redirected somewhere to login and get a 
> cookie for authentication; e.g., Yahoo!, Google, Amazon, etc. Same situation, but slightly 
> different use case.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Mar 2007 13:56:22 +0000

The problem is that current browsers wouldn't know what to do with  
it, so adoption will be difficult at best.

On 15/03/2007, at 1:55 PM, Thomas Roessler wrote:

>> somewhere to login and get a

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 15 Mar 2007 15:11:11 +0100

IE7 displays it as well.

Fortunately I stay less in hotels, but I can see the use case for the  
login forms. Non-browser clients would benefit from detecting the  
difference between what they wanted and what they got.

Cheers,

Stefan *death-to-ua-sniffing*

Am 15.03.2007 um 14:48 schrieb Mark Nottingham:

>
> After being in hotels for a few weeks, I'm starting to wonder  
> whether a new 2xx HTTP status code could be defined whose semantic  
> is "This isn't what you asked for, but here's some information  
> about how to get network access so you can eventually get it."
>
> Safari and Firefox do (see <http://www.mnot.net/test/222.asis>).  
> IE? 4xx might be more appropriate, but I despair of "friendly"  
> error messages. (thought they could be padded, I suppose).
>
> centre / etc. asking for cash in order to get network access, and  
> not get horribly messed up as a result.
>
> somewhere to login and get a cookie for authentication; e.g.,  
> Yahoo!, Google, Amazon, etc. Same situation, but slightly different  
> use case.
>
> Thoughts?
>
> --

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 15 Mar 2007 15:13:48 +0100

>messages. (thought they could be padded, I suppose).

We have 402 and well-known workarounds for "friendly" error messages?

>Google, Amazon, etc. Same situation, but slightly different use case.

I don't multi-redirect login schemes merit further support.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Joe Orton <[email-masked]>
Date: Thu, 15 Mar 2007 14:15:07 +0000

> get network access so you can eventually get it."

I don't see why any existing 50x wouldn't work for this case: 502/503 
particularly.  Using any 2xx or 3xx is clearly broken when a gateway 
interjects a "pay to play" error response.

joe

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 15 Mar 2007 10:47:35 -0400

Sounds more like a 3xx, perhaps even 303?

The hard part is getting these proxies to support it, of course.

Mark.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Mar 2007 14:53:37 +0000

Hmm, 3xx doesn't seem right; there might be temporary redirects along  
the way (indeed, most of these sorts of things already use them);  
it's the status code of the place where you end up that's interesting.

5xx implies server-side error, so that's not appropriate (unless you  
consider their requirement for money an error!)

402 is reserved, and I think the original intent was making a payment  
to the origin server, not to the folks who give you the network to  
get there...

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 15 Mar 2007 16:13:59 +0100

Well, from the existing codes 409 sounds best to me.

"The response body SHOULD include enough information for the user to  
recognize the source of the conflict. Ideally, the response entity  
would include enough information for the user or user agent to fix  
the problem;"

Cheers, Stefan

Am 15.03.2007 um 15:53 schrieb Mark Nottingham:

>
> Hmm, 3xx doesn't seem right; there might be temporary redirects  
> along the way (indeed, most of these sorts of things already use  
> them); it's the status code of the place where you end up that's  
> interesting.
>
> 5xx implies server-side error, so that's not appropriate (unless  
> you consider their requirement for money an error!)
>
> 402 is reserved, and I think the original intent was making a  
> payment to the origin server, not to the folks who give you the  
> network to get there...
>
>
>
>>> whether
>>> Yahoo!,

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany

---

From: Eric Lawrence <[email-masked]>
Date: Thu, 15 Mar 2007 09:20:06 -0700

I'm not sure why a 403 isn't appropriate (or at least more appropriate for 409) for this case?

In my mind, the much more interesting question is how to handle a HTTPS connection in this scenario.  The hotel never provides a certificate which correctly validates (since they can't get a wildcard certificate that matches every link the user might choose to initially visit).   The resulting certificate name mismatch leads to error dialogs, failed navigations, etc.

Eric Lawrence
Program Manager
Internet Explorer Networking

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Thursday, March 15, 2007 6:48 AM
To: [email-masked] Group
Subject: New Status Code -- 2xx Greedy Hotel?

Thoughts?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Mar 2007 16:30:15 +0000

> appropriate for 409) for this case?

If an automated agent (e.g., RSS aggregator) sees a 403, they might  
take some action on it (e.g., unsubscribing, or calling the feed  
'dead'), because they think that the resource itself has a problem.  
Not sure if that's a huge issue, it could probably be handled well if  
everyone gravitated towards 403 as the solution for this particular  
problem. It seems to me that it's mostly a matter of education, and a  
distinct status code might make that easier.

I agree that 403, or maybe 400, is the best existing status code to  
use. 409 doesn't seem appropriate at all.

> In my mind, the much more interesting question is how to handle a  
> HTTPS connection in this scenario.  The hotel never provides a  
> certificate which correctly validates (since they can't get a  
> wildcard certificate that matches every link the user might choose  
> to initially visit).   The resulting certificate name mismatch  
> leads to error dialogs, failed navigations, etc.

Good question. Most of the ones I've seen recently redirect initially  
to a non-HTTPS site to avoid the certificate mismatch popup.

> From: [email-masked] [mailto:ietf-http-wg- 
> [email-masked]] On Behalf Of Mark Nottingham

---

From: Eric Lawrence <[email-masked]>
Date: Thu, 15 Mar 2007 09:33:07 -0700

Most authenticating proxies today will return a 407 and then a 403 if any automatically-provided credentials fail, so unsubscribing definitely seems like a bad idea on the part of the automated user-agent.

<<Good question. Most of the ones I've seen recently redirect initially
to a non-HTTPS site to avoid the certificate mismatch popup.>>

The certificate mismatch popup or blocking page will also appear when the ~redirect~ is received by the browser, so the user still gets the warning.  Worse still, they may choose not to proceed, and thus never see the "please give us money" page.

-Eric

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 15 Mar 2007 10:04:24 -0700

It's not just 'pay to play'... I've seen several 'free
access but you must register and agree to terms & conditions'
services with similar restrictions.

And I think this is an additional consideration that
would fit into an update to RFC 3205/BCP 56 (on the
use of HTTP as a substrate...).

Larry

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 15 Mar 2007 17:12:42 +0000

> payment to the origin server, not to the folks who give you the  

I think 402 is the best status code here. There's nothing in RFC2616  
that says intermediate servers can't request payment too.

- Nicholas.

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 16 Mar 2007 09:49:15 +1300

Isn't this a symptom of the problem with the initial redirect code?

If the automated client thinks it's being redirected to an alternative 
source of the same resource, then it will treat it differently to if it 
thinks it is being diverted.  A human (hopefully) can tell the difference.

Can't we solve this one with the solution to the problems of 301/302 and 
GET following POST?

I.e. introduce a divert code, which specifically means, "you've been 
diverted to here", rather than "you can get what you were looking for here".

Could use 307 for that?  e.g, clarify the intent of 307 to mean a 
diversion rather than a detour (i.e. different destination rather than 
different path to same destination).

One more for the pot.

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 16 Mar 2007 09:51:29 +1300

sorry - meant 303 not 307.

Adrien de Croy wrote:
> source of the same resource, then it will treat it differently to if 
> it thinks it is being diverted.  A human (hopefully) can tell the 
> difference.
>
> Can't we solve this one with the solution to the problems of 301/302 
> and GET following POST?
>

---

From: David Morris <[email-masked]>
Date: Thu, 15 Mar 2007 14:57:28 -0800 (PST)

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 16 Mar 2007 21:36:52 +0100

fre 2007-03-16 klockan 09:49 +1300 skrev Adrien de Croy:

> Could use 303 for that?  e.g, clarify the intent of 303 to mean a 

Hmm.. will probably work most of the time with existing software but
does not match well with the definition of 303..

I think defining 402 is the right thing for the cases discussed
(payment, or accepting terms of use etc). I would also propose adding a
Location header in it's response as reference where the payment agent
(or similar) can be found, plus the requirement that the response body
as such is well useful for finding the payment agent.

It's not really a redirect. It's "sorry, you can't access this until you
have done XXX", so a 4xx is very appropriate.

A user agent (automata or interacting with a real user) handling a 402
as if it was a permanent 404 is well, broken, and needs to be fixed.
Education of software authors can help there.

How quick the industry will be in adopting this scheme is another
question, but in terms of specifications it would fill a noticeable gap.

But I also maintain that the whole idea of solving the network access
"payment" problem by temporary firewalling and redirection of port 80 is
by default a flawed design. Should be possible to come up with something
much smarter than that at the link level. But thats far outside our
intended charter.

Regards
Henrik