Closed ianbjacobs closed 7 years ago
We discussed this in Lisbon, so I've had a bit of time to think about it already --
Strong preference for option 2 (HTTP Link header) -- I think its "con" list is pretty compelling. :)
Option 4 also seems workable. I don't think human readability is a major consideration here -- the only people who would try to resolve these URLs are developers, and JSON shouldn't be a problem for them.
I am comfortable with 2.
I would add a con for 2 of: "More challenging and time consuming to developers to integrate"
Can we define more than 1 of these with an order of preference for browsers to follow?
That way those that are able to do the more correct ones that require fewer request round-trips can implement those and those who are not able to can do the simpler ones on the understanding that they may be impacting the user experience.
At the 5 January 2017 call [1] there was a preference for option 2 (HTTP Link Headers). Google and Samsung are going to experiment and bring findings back to the group by 26 January. We also plan to do a little homework on the extent of support of HTTP Link Headers, though it was pointed out that the number of registered link relationships [2] is encouraging.
We picked this rel string: payment-method-manifest
Ian [1] https://www.w3.org/2017/01/05-wpwg-minutes#item02 [2] http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1
Browsers support Link
headers, in that they're exposed anywhere else HTTP header fields are exposed, such as Fetch and XmlHttpRequest.
Some browsers also support a handful of relations natively, e.g., stylesheet
, prefetch
, preload
. So the barrier to them directly supporting a new relation (if they choose to) shouldn't be too high.
Link
headers work for us.
@mnot I think the concern is more about how easy it is for developers to service HEAD
requests.
My take from the call was that this is not considered a blocking issue as we expect "hosting" a payment method to be a fairly sophisticated exercise.
I looked into this and it appears to be quite easy. Here's how you do it in Node.js:
app.head('/bobpay', function(req, res) {
res.status(200).links({
'payment-method-manifest': 'payment-manifest.json',
}).end();
});
And here's PHP:
<?php
header("Link: <payment-manifest.json>; rel=\"payment-method-manifest\"");
?>
@rsolomakhin how about if my domain is hosted on GH Pages? 😄
If you have access to a server and the ability to do more than just put static files on that server then I agree it's pretty easy.
When defining these things it's always nice to think about the developer that doesn't have these luxuries. In this case though, I think we're safe requiring them.
At today's teleconference [1] we resolved that:
Editorial notes:
[1] https://www.w3.org/2017/02/02-wpwg-minutes#item04 [2] https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
@zkoch wrote a first proposal: https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
Since then there have been a number of suggestions. Here is a first pass summary of some pros and cons (help welcome!):
1) Hard-coded URL Pro: Simple configuration Con: Limits server to one manifest file per payment method. Squats URI space.
2) HTTP Link header (used in conjunction with caching) Pro: Greater flexibility in naming, serving multiple resources.
3) Content negotiation Pro: One URL Con: (1) challenging for server operators to deploy correct mime types; conneg is even more complex (2) Proxies and caches do not always work well with conneg
4) Serve JSON for PMI; link to human readable content from there Pro: Optimizes for the information we know today we want to associate with a PMI. Still allows follow your nose to get more information. Con: People get back data instead of human readable info by default so less friendly.