reconsider extra level of indirection for retrieving a manifest?

[dbaron]

This issue came up in the TAG during discussion of the TAG review in w3ctag/design-reviews#162.

One of the things that bothered a number of us about the specification was that the process for retrieving a manifest from a payment method identifier was to look for a Link response header with rel="payment-method-manifest" from a GET or HEAD response on the payment method identifier URL. This seemed bad for two reasons:

• there was an extra seemingly-unneeded level of indirection
• the process just seemed out of place in the context of the Web platform

In w3ctag/design-reviews#162 (comment) @triblondon enumerated four possibilities (including the spec's current behavior):

1. what the spec does now, where a Link header is used from the identifier URL to find the manifest (disadvantage: extra level of indirection)
2. require that the URL used as an identifier point directly to the payment method manifest (disadvantage: URL used as the identifier is less human-readable)
3. making the URL of the manifest be a /.well-known/ URL (RFC 5785) that can be formed from the identifier URL without any network interaction (disadvantage: has to be at that URL)
4. using a request header (e.g., Accept) to allow the identifier URL to produce a payment method manifest (disadvantage: requires using Vary: Accept, although that may often be needed anyway)

Within the TAG, there seemed to be the most support for (and no objection to) (2). However, we're certainly missing some of the context that the working group has, so we wouldn't insist on such a change (certainly not at this stage).

That said, we'd be interested in understanding more about the process that led the working group to make the choice it currently did, and whether perhaps there's another option that meets everybody's requirements.

[zkoch]

Thanks for the review!

There's actually a another disadvantage to (2) besides being less human readable and more error prone, which is that: it requires the existence of a manifest file. A manifest is a useful tool, but we don't require it. I think there are other issues, but that's the main one.

[dbaron]

I guess not requiring a manifest is another interesting question -- should people really be using new payment methods on the Web without giving any information about how to use them?

[triblondon]

Hey @zkoch we're still a bit perplexed about how you can practically use a custom payment method without saying anything about how it works. I'm also keen to clarify your comment about 'more error prone' - can you confirm my understanding that it is exactly as error prone as any mechanism that requires specifying a full URL of a resource, eg a link from one website to another?

[triblondon]

w3ctag/design-reviews#162 (comment)

[cvan]

I agree that discovering and accessing the URL to the Payment Method Manifest via a Link response header is less than ideal for web developers and service providers.

if a GET/HEAD request is necessary for identifying the URL, web developers will already need to configure their servers to set such response headers (e.g., Link: </pay/payment-manifest.json>; rel="payment-method-manifest"). if developers have the ability to set response headers, they'll likely also have the ability to conditionally serve different response bodies for a Web-App Manifest. as mentioned in #10 (comment), developers (and their CDNs) would need to introduce and respect a Vary header.

I'm new to this discussion, so forgive my ignorance. are there alternatives that have been proposed elsewhere or in other TAG reviews?

[rsolomakhin]

@cyberphone proposed an excellent solution in rsolomakhin/rsolomakhin.github.io#28:

If there is no Link, Chrome might as well perform GET on the same URL.

I think this is a great idea. We should add this to the spec and ship it in Chrome :-D

[domenic]

Do we think it's a good idea to issue two requests, one HEAD then one GET? Or would it be better to just issue a single GET, and either ignore the body or use it, depending on the headers?

[rsolomakhin]

A single GET makes more sense from the standpoint of architecture.

The implementation (not the spec) should also have a fallback to HEAD if the GET fails for those payment handlers that explicitly wait for a HEAD request. We should measure how often the fallback succeed when the initial GET failed. When that number is close to zero, the implementation can remove the HEAD fallback.