On Wed, Dec 31, 2014 at 9:39 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > > Since HTTP 402 directed to the *browser window* doesn't apply, we are > rather talking > about a proxy that in the background does the communication. In your case > through XHR. > > If I were to design such a scheme I would let the proxy call return two > responses > both having the response code 200. One message would be like "OK" which > I understand > should trigger the proxy to perform a URL access to the requested > resource. The > other response would be "Payment Required + associated information on what > kind of > payments that are accepted and how much money that is requested. > I think a 402 would allow better handling. A 200 response would have the requested content where 402 would indicate payment were necessary. If both types of response were 200, you are saying that neither response contains the requested media - or it is somehow embedded in the response. I would advocate handling it at protocol level (402 / 200) so you don't have to mess with the response when it contains media. > So even if one could do the same thing with HTTP 402 the question remains: > Why would > this be better unless 402 got a built-in payment hook[*] in the browser? > I would be > interested hearing Manu's opinion on this since he and Digital Bazaar > really are > the only parties who have provided CG specifications. > A 402 response could always include headers with the necessary information. Non-compliant browsers / applications would simply read this as any other 400 "access denied" message.
Received on Thursday, 1 January 2015 19:49:03 UTC