- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 02 Jan 2015 14:36:32 -0500
- To: public-webpayments@w3.org
- Message-ID: <54A6F340.1030401@openlinksw.com>
On 12/31/14 10:36 AM, UniDyne wrote: > On Wed, Dec 31, 2014 at 9:39 AM, Anders Rundgren > <anders.rundgren..net@gmail.com > <mailto: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. Yes! That's the fundamental point. Happy New Year Everyone. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 2 January 2015 19:36:55 UTC