What causes "Unable to parse filename from url's path: {}" in epi052/feroxbuster?

Append a filename to the wordlist URL (remove the trailing slash and point at the actual file)

Unable to parse filename from url's path

Error message

Unable to parse filename from url's path: {}

What it means

Once path_segments is obtainable, wrapped_main takes the last segment as the filename; if the final path segment is empty (e.g. URL ends with '/'), next_back() yields None and it bails with this message. The downloaded wordlist cannot be named/checked, so the scan aborts.

Solutions

Append a filename to the wordlist URL (remove the trailing slash and point at the actual file)
Download the file locally and pass a filesystem path
Check the final (post-redirect) URL and use it directly

Example fix

// before
--wordlist https://example.com/lists/
// after
--wordlist https://example.com/lists/common.txt

Defensive patterns

Strategy: validation

Validate before calling

const last = new URL(wordlistUrl).pathname.split('/').filter(Boolean).pop(); if (!last) throw new Error('URL must end with a filename, not /');

Type guard

function hasFilename(u) { try { return Boolean(new URL(u).pathname.split('/').filter(Boolean).pop()); } catch { return false; } }

Prevention

Point wordlist URLs at actual files, not directories
Strip trailing slashes from wordlist URLs
Verify the post-redirect URL ends with a filename

When it happens

Trigger: --wordlist URL whose path ends with a trailing slash or whose last segment is empty, e.g. https://example.com/lists/ — path_segments().next_back() is Some("") being filtered or None depending on the split, causing the bail.

Common situations: Directory-style raw URLs, shorteners redirecting to directory URLs, or manually typed URLs that end with '/'.

Understand the failure class

Background: "Invalid URL" errors: why new URL(), URI.parse, and reqwest::Url reject your string — missing scheme, whitespace, and bad path format — this error's family across 39 libraries.

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of epi052/feroxbuster@1f595dab5c (2026-09-13). Data as JSON: /api/errors/8d6ce5404a9cafad. Report an issue: GitHub.

Appendix: source

Thrown at src/main.rs:280

                    "Unable to download wordlist from remote url: {source}"
                ))?;

                if !response.status().is_success() {
                    // status code isn't a 200, bail
                    bail!(
                        "[{}] Unable to download wordlist from url: {}",
                        response.status().as_str(),
                        source
                    );
                }

                // attempt to get the filename from the url's path
                let Some(mut path_segments) = response.url().path_segments() else {
                    bail!("Unable to parse path from url: {}", response.url());
                };

                let Some(filename) = path_segments.next_back() else {
                    bail!(
                        "Unable to parse filename from url's path: {}",
                        response.url().path()
                    );
                };

                let filename = filename.to_string();

                // read the body and write it to disk, then read it back as a wordlist
                let body = response.text().await?;
                std::fs::write(&filename, body)?;

                append_words_from_path(&filename, &mut words, &mut seen)?;
            } else {
                match append_words_from_path(source, &mut words, &mut seen) {
                    Ok(()) => {}
                    Err(err) => {
                        // preserve the legacy secondary-wordlist fallback, but only when the
                        // user is relying on a single local source (i.e. didn't supply an

View on GitHub (pinned to 1f595dab5c)