Re: HTTP 402 (payment required) -- the missing link

On 17 June 2015 at 19:45, David I. Lehn <dil@lehn.org> wrote:

> On Tue, Jun 16, 2015 at 8:34 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> > On 17 June 2015 at 02:23, David I. Lehn <dil@lehn.org> wrote:
> >> On Tue, Jun 16, 2015 at 7:57 PM, Melvin Carvalho
> >> <melvincarvalho@gmail.com> wrote:
> >> > I've implemented HTTP 402 a few times for payment protected resources.
> >> > ...
> >> > If payment is required, how does the client know what to do next?
> >> > ...
> >> > What about sending a Location: header telling the client where to go
> >> > next?
> >> >
> >> > Then the client can find all the information about how to pay, their
> >> > balance, the cost etc.
> >> > ...
> >>
> >> Won't user agents only follow that Location for 3xx codes?  How about
> >> just including human and/or machine readable info in the 402 response
> >> content?
> >
> > Seems possible.  But are you allows to return data with a 4xx?  Im not
> sure
> > on this ...
> >
>
> Sure.  For example see all the fancy 404 HTML pages out there.  You
> could also do content negotiation and return machine readable data
> when appropriate.
>

OK, so I guess there's 4 options:

1.  Return information in the headers

I think http 401 does this also.

2. Return a Location header that acts as a redirect

The discussion of HTTP 209 had this as a feature

3. Return a document via content negotiation

I dont see why not, but it "feels" wrong.  For example looking at http 404,
it's rare that the page you get back actually is processes further.  It
might just be me.

4. A combination of (1), (2) and (3)

Good flexibility but requires more implementation.

I guess given that it will be mainly implemented over AJAX + HTTP (+TLS)
returning a JSON payload could be a nice way to do it ...

I'll ask around, tho am interested in feedback on which seems a good
practice.  I think the IETF or HTTP WG may be the best people to ask here
...


>
> -dave
>