?
or &
which separate multiple bitcoinparam
. Based on the examples in the rest of the spec, we assume that ?
is always a reasonable separator. The &
character is also allowed in non-initial positions.
?
or &
which separate multiple bitcoinparam
. Based on the examples in the rest of the spec, we assume that ?
is always a reasonable separator. The &
character is also allowed in non-initial positions.
Ensure that the bitcoin URL spec includes the `?` or `&` which separate multiple `bitcoinparam`. Based on the examples in the rest of the spec, we assume that `?` is always a reasonable separator. The `&` character is also allowed in non-initial positions.
?
is only allowed in the initial position (between the address and the arguments), and &
as the seperator between arguments.
The example further down in the spec uses ? as the separator between elements; I can update the patch to fix that as well.
Modern HTML prefers using ; to & as an argument separator (no encoding issues)—should we support that as well?
Oh? In that case I’m not sure. May be an error in the spec. Maybe mail the owners.
Have you tested whether any of the implementations accepts ?
between arguments?
Switched to &
and ;
It would be nice to have an example with &
and ;
in (for example) the label text, to demonstrate proper escaping.
;
here as separator.
Do any of the current clients allow this?
Is there any reason to allow different seperators?
The standard reason for recommending the use of ;
is that HTML authors are notoriously bad at properly escaping &
in URLs. That is, a proper bitcoin link in HTML should be:
0<a href="bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jr">Pay now</a>
but almost everyone forgets to escape the &
properly. See http://stackoverflow.com/questions/3481664/semicolon-as-url-query-separator for more discussion.
The drawback is that authors now have to ensure that both &
and ;
in values are properly percent-encoded.
;
as parameter separator.
I guess in general custom code needs to be written to handle it, whereas all URI parsing libraries handle &
.