chore: fix incorrect URL path resolution

[mdqst]

some API paths like tx/..., block-height/..., and scripthash/... were being joined without a leading /.
since Url::join interprets them as relative, the last segment of the base URL was being replaced instead of appended.

[vercel]

@mdqst is attempting to deploy a commit to the distributed-crafts Team on Vercel.

A member of the Team first needs to authorize it.

[gemini-code-assist]

Summary of Changes

Hello @mdqst, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue where certain API endpoint paths were being incorrectly resolved by the Url::join method. By prepending a forward slash to these paths, the system now correctly interprets them as absolute paths relative to the root, ensuring they are appended to the base URL as intended rather than replacing existing segments. This fix guarantees proper construction of API requests for various data retrieval operations.

Highlights

• URL Path Resolution: API paths for various Esplora endpoints (e.g., tx/..., block-height/..., scripthash/...) now include a leading forward slash. This ensures that Url::join correctly appends these paths to the base URL, preventing unintended replacement of the last segment of the base URL.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to fix an issue with URL path resolution. However, the current approach of adding a leading slash to paths creates a critical issue: it breaks support for Esplora instances hosted under a path prefix (e.g., behind a reverse proxy). The change makes all API paths absolute to the host, ignoring any path in the base URL.

I've left a detailed comment on the first occurrence of this pattern, explaining the problem and suggesting a more robust solution. The recommended approach is to enforce a trailing slash on the base URL within the client's constructor and consistently use relative paths (without a leading slash) for all API calls. This will ensure correct behavior for all valid base URL configurations.

[gemini-code-assist]

This change introduces a significant issue for users who run Esplora behind a reverse proxy with a path prefix.

By adding a leading slash, you are making the path an "absolute-path reference". According to the url::Url::join documentation, this resolves the path from the origin of the base URL, ignoring any path component in the base URL.

For example, if a user configures the client with a base URL like https://example.com/esplora/ (note the trailing slash, which is correct for path prefixes), the behavior changes as follows:

• Before (correct): url.join("tx/...") would result in https://example.com/esplora/tx/....
• After (incorrect): url.join("/tx/...") would result in https://example.com/tx/....

The issue described in the pull request description ("the last segment of the base URL was being replaced") happens when the base URL has a path but lacks a trailing slash (e.g., https://example.com/esplora). The correct way to handle this is not to make all paths absolute, but to ensure the base URL is correctly formed.

I recommend a more robust solution:

1. Revert this change and all similar changes in this PR.
2. In EsploraClient::new_with_url, ensure that the parsed Url always has a path ending with a trailing slash. This makes path joining predictable. You could do something like this:

   pub fn new_with_url(esplora_url: String) -> Result<Self> {
       let mut url = esplora_url.parse::<Url>()?;
       if !url.path().ends_with('/') {
           url.path_segments_mut()
               .map_err(|_| eyre::eyre!("URL cannot be a base"))?
               .push("");
       }
       Ok(Self { url, cli: Client::new() })
   }

3. Audit all other API calls in this file and ensure they all use relative paths (no leading slash) for consistency. For example, get_tx_hex and get_tx_info currently use absolute paths and should be changed.

This approach will correctly handle all base URL configurations, including those with path prefixes.

Suggested change

	&self.get(&format!("/tx/{txid}/merkleblock-proof")).await?,
	&self.get(&format!("tx/{txid}/merkleblock-proof")).await?,

[gregdhill]

@mdqst please check this comment

[mdqst]

sry, my bad. closed.