payjoin-cli receiver response causing reqwest failure with `InvalidContentType`

[mehmetefeumit]

Is there an existing issue for this?

• [x] I have searched the existing issues

Which crate is this issue for?

payjoin-cli

How did you obtain this crate?

Package manager

Features

No response

What version of the selected crate are you using?

payjoin-cli 0.2.0

Current behavior

payjoin-cli bip78 receiver responds with a payload which does causes the sender to panic with received corrupt message of type InvalidContentType error message from reqwest. Note that this only happens when the user runs the bip78 listener, as it initializes a listener on the local machine.

Hypothesis

Dug around a bit, and looks to me like we are initializing a plain HTTP listener in the receiver code unless the _manual-tls feature is enabled. So the default behavior initializes a plain HTTP listener, but then the PJ endpoint we create is "https://localhost:3000".

Expected behavior

Correct bip78 receiving and sending behavior.

Steps to reproduce

1. Start a local bitcoind -regtest, load the wallet, etc.
2. Only have bitcoind credential details in both the sender and receiver config files.
3. On the receiver side, run payjoin-cli --bip78 receive 4000
4. On the sender side, run payjoin-cli --bip78 send --fee-rate 1 "<PAYJOIN_URI>

Relevant log output

Following the steps outlined above should result in the following:

It should result in the following error on the sender side:

Sending fallback request to https://localhost:3000/?v=1&additionalfeeoutputindex=1&maxadditionalfeecontribution=68&minfeerate=1
Error: HTTP request failed

Caused by:
    0: error sending request for url (https://localhost:3000/?v=1&additionalfeeoutputindex=1&maxadditionalfeecontribution=68&minfeerate=1)
    1: client error (Connect)
    2: received corrupt message of type InvalidContentType

Operating system and version

Debian 12 (Bookworm)

[DanGould]

This is expected behavior to me but perhaps improperly documented. Without _manual-tls I expect you to terminate TLS on your own with a reverse proxy, since "http://" && not(".onion") payjoin produces an UnsecuredEndpoint error and I don't want to make a danger feature that overrides this error from being thrown. Perhaps there's a better way to configure the pj= Url that gets displayed in the BIP21, but I wonder if the receiver should just print "MAKE SURE YOU HAVE A REVERSE PROXY TERMINATING TLS" or something like that since I treat bip78 as a second class reference-only citizen at this point.

[mehmetefeumit]

Sounds good. I'll have it note that down somewhere. I was playing with Caddy for the reverse proxy but wasn't sure to what extend this was expected behavior.

[DanGould]

Ok, closing criteria for this issue is some obvious println on receiver startup when not using _manual-tls then