View Issue Details

IDProjectCategoryView StatusLast Update
0004601Talerotherpublic2016-10-11 17:28
ReporterMarcello Stanisci Assigned ToFlorian Dold  
PrioritynormalSeveritytweakReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.0 
Target Version0.1Fixed in Version0.1 
Summary0004601: JS-less alternative
DescriptionAs of now, the JS-less version of merchants work by embedding anything needed
by the wallet in a 'data-taler-*' attribute. We could also use HTTP headers for that, like X-Taler-*. The point is that sometimes the user does not get HTML, so the data-taler-* approach would not work.

Other comments?
TagsNo tags attached.


Florian Dold

2016-07-08 21:17

manager   ~0010980

It makes sense to eventually allow the use HTTP headers for handling payments. But right now is too early.

For a first version of JS-less payments it is easier to use HTML data attributes, since we can polyfill the translation to DOM events outside of the wallet.

Handling headers requires more effort and additional signaling between components in the wallet, and there might be some unexpected difficulties in how the webRequest in WebExtensions (which is needed to get header information for requests) works.

Christian Grothoff

2016-07-09 17:24

manager   ~0010982

I disagree, I think we should use HTTP headers soon, especially as we cannot be sure that the body will be HTML. I think you were the one pointing this out, Florian. So we should transition to HTTP headers ASAP, likely just when we use 402 for signaling.

Florian Dold

2016-07-09 17:35

manager   ~0010984

Are you saying that we should completely move to HTTP headers, or should we also support a JavaScript API for payments?

Note that at least the initial fulfillment page (before we have the cookie to get the actual resource) *MUST* generally be HTML (or something that is put in a DOM by the browser), otherwise the payment is not implementable with WebExtensions. With WebExtensions we can *inspect* HTTP headers, but we can't modify responses. Thus if we want to purchase, we must first get an HTML response so that the wallet can act on headers (otherwise the content script won't be injected). If there are confusions around this, we should discuss it offline before we make a decision.

W3C is doing both, BTW. But for HTTP Payments, they assume that they're completely automated, they don't spec the browser interaction / user interaction part at all. Which is kind of bad.

Christian Grothoff

2016-07-09 19:47

manager   ~0010985

We keep supporting the JavaScript signal API, but for the JS-less version, I think we should signal via 204/402 and HTTP headers.

I don't quite think you're right about the mp3 example, and yes, I think an mp3 should be a valid fulfillment page. Naturally, that's for the 200 OK, not for the payment required (402).

As for the content script having to be injected, that would already not work with my envisioned 204-handling for the bank. But who says we _must_ do this via JS injection? Can't the extension simply take over given the right status code and headers?

Florian Dold

2016-07-09 21:17

manager   ~0010986

Could you please explain what you mean by "my envisioned 204-handling for the bank"? Otherwise I can't really respond properly without that context ;-)

And no, unfortunately the extension can't simply take over given the right status code and headers. For session state (cookies) to be set properly, the deposit permission must be HTTP POST-ed from the same origin as the fulfillment page.

In order to do that, we need the 402 to be HTML (so that a page with a DOM is created and the content script is injected, which will then do the POST).
This is a restriction of WebExtensions that I believe we discussed in detail already.

But this is not a bad thing, since for browsers without a wallet we want the 402 to contain HTML anyway.

And of course, an mp3 can be a valid fulfillment page (after completed payment), I never said that it wasn't.

Anyway, I'm happy with 402 and headers, but at least for browsers I don't see any advantage. Yeah, you could do the optimization with the contract inlined in the header. But considering that Apache and nginx limit headers to 8KB, this is not a good idea anyway. Some proxy might generate a 414 (Request-URI Too Large), we don't want that.

Christian Grothoff

2016-07-09 22:52

manager   ~0010987

1) I had discussed with Marcello what an appropriate way to do a JavaScript-less triggering of the wallet from the bank. If we, just like with the merchant, want to trigger on a status code, we should use one that is not too common. Also, as there is then not really a body, 204 is appropriate. So the idea was that the wallet would get a 204 status code from the bank to initiate withdrawal, again with headers providing the necessary banking details.

2) Ah, the cookie issue. Yeah, I guess we can require the 402 page to be in HTML, still, I think it's cleaner to go with headers. As for the header limit, my discussion with Marcello was to have two headers, one with a URI (dear wallet, download contract from here) and one with an inline JSON contract. So basically it'd be up to the merchant to decide: extra RTT vs. possibly wasted bandwidth. So for short contracts, x-taler-contract-json would be a good choice, and for big ones X-taler-contract-uri would be better.

3) I wonder if the 204 is a bad idea for the cookie-reason, maybe we'll need to revisit that choice as 204 replies must not have _any_ body.

Florian Dold

2016-07-09 23:25

manager   ~0010988

Regarding (2) I like that proposal.

Don't we need the contract information also in the HTML? If not, enabling/installing the extension after the page has loaded won't work, headers can only be captured on page load.

Or do we not consider this use case?

The WPWG Payments HTTP API has not decided yet whether they want to link to the contract in the location header of 402, or to have the contract (=PaymentRequest in their terminology) in the body. The latter wouldn't be implementable with WebExtensions, AFAIK.

Florian Dold

2016-09-12 23:52

manager   ~0011111

At least for the merchant, it's implemented and documented (in the paper).

Payments are triggered with 402.

Issue History

Date Modified Username Field Change
2016-07-08 16:51 Marcello Stanisci New Issue
2016-07-08 21:17 Florian Dold Note Added: 0010980
2016-07-09 17:22 Christian Grothoff Assigned To => Marcello Stanisci
2016-07-09 17:22 Christian Grothoff Severity minor => tweak
2016-07-09 17:22 Christian Grothoff Status new => assigned
2016-07-09 17:22 Christian Grothoff Product Version => 0.0
2016-07-09 17:22 Christian Grothoff Target Version => 0.2
2016-07-09 17:24 Christian Grothoff Note Added: 0010982
2016-07-09 17:24 Christian Grothoff Assigned To Marcello Stanisci => Florian Dold
2016-07-09 17:35 Florian Dold Note Added: 0010984
2016-07-09 19:47 Christian Grothoff Note Added: 0010985
2016-07-09 21:17 Florian Dold Note Added: 0010986
2016-07-09 22:52 Christian Grothoff Note Added: 0010987
2016-07-09 23:25 Florian Dold Note Added: 0010988
2016-09-12 23:52 Florian Dold Note Added: 0011111
2016-09-12 23:52 Florian Dold Status assigned => resolved
2016-09-12 23:52 Florian Dold Resolution open => fixed
2016-09-19 00:51 Christian Grothoff Fixed in Version => 0.1
2016-09-19 00:51 Christian Grothoff Target Version 0.2 => 0.1
2016-10-11 17:28 Christian Grothoff Status resolved => closed