• Added Wiley TDM API fulltext fetcher for PDF downloads from Wiley journals
• Extended fulltext fetcher infrastructure to support per-fetcher HTTP headers
• Refactored download flow to propagate authentication headers through validation and download steps
• Updated preferences UI to include customizable key fetchers in web search settings
• Added comprehensive unit tests for WileyFetcher and header propagation

New Wiley TDM API fulltext fetcher implementation

jablib/src/main/java/org/jabref/logic/importer/fetcher/WileyFetcher.java

Added getDownloadHeaders default method to interface

jablib/src/main/java/org/jabref/logic/importer/FulltextFetcher.java

Extended to include HTTP headers in result

jablib/src/main/java/org/jabref/logic/importer/FetcherResult.java

Description

A new public method overload introduces a boolean flag parameter, which makes call sites ambiguous
and reduces API clarity. This violates the guideline to avoid boolean parameters in public methods.

Code

jabgui/src/main/java/org/jabref/gui/fieldeditors/LinkedFileViewModel.java[R456-462]

 public void download(boolean keepHtmlLink) {
+        download(keepHtmlLink, Map.of());
+    }
+
+    public void download(boolean keepHtmlLink, Map<String, String> headers) {
     LOGGER.info("Downloading file from {}", linkedFile.getSourceUrl());
     if (!linkedFile.isOnlineLink()) {

Evidence

PR Compliance ID 13 forbids introducing new public methods with boolean parameters controlling
behavior. The PR adds public void download(boolean keepHtmlLink, Map headers).

AGENTS.md
jabgui/src/main/java/org/jabref/gui/fieldeditors/LinkedFileViewModel.java[456-462]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new public overload `download(boolean keepHtmlLink, Map<String, String> headers)` introduces a boolean flag parameter, which is discouraged for public APIs.
## Issue Context
Boolean flags make call sites unclear (e.g., `download(true, headers)`), and the compliance checklist requires avoiding boolean parameters in new public methods.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/fieldeditors/LinkedFileViewModel.java[456-462]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Authenticated downloads can fail after HTTP redirects because URLDownload.openConnection() follows
redirects by creating a new URLDownload instance without copying previously added headers, so the
redirected request drops the Wiley-TDM-Client-Token. This can lead to passing the PDF “isPDF”
validation (which keeps headers) but failing the actual file download when a redirect occurs.

Code

jabgui/src/main/java/org/jabref/gui/linkedfile/DownloadLinkedFileAction.java[R129-132]

     try {
         URLDownload urlDownload = new URLDownload(downloadUrl);
+            downloadHeaders.forEach(urlDownload::addHeader);
         if (!checkSSLHandshake(urlDownload)) {

Evidence

This PR starts attaching per-fetcher headers to URLDownload instances used for downloading (both in
the initial URLDownload and in the FileDownloadTask). However, URLDownload.openConnection()
implements redirect handling via recursion using new URLDownload(newUrl), which reinitializes the
internal header/parameters map (only User-Agent is set in the constructor), so the redirected
request is sent without the authentication headers. In contrast, the MIME-type/PDF check path uses
Unirest calls that include .headers(parameters) on each request, so it can succeed even when the
later openConnection-based download fails after redirect.

jabgui/src/main/java/org/jabref/gui/linkedfile/DownloadLinkedFileAction.java[129-137]
jabgui/src/main/java/org/jabref/gui/linkedfile/DownloadLinkedFileAction.java[296-320]
jablib/src/main/java/org/jabref/logic/net/URLDownload.java[334-407]
jablib/src/main/java/org/jabref/logic/net/URLDownload.java[125-176]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Authenticated fulltext downloads can break on redirects because `URLDownload.openConnection()` handles redirects by creating a fresh `URLDownload(newUrl)` which does not inherit previously added headers (e.g., `Wiley-TDM-Client-Token`). This can cause downloads to fail after a 30x redirect even though the PDF validation step succeeds.
### Issue Context
The PR introduces per-fetcher download headers and correctly applies them to `URLDownload` instances. The redirect behavior in `URLDownload.openConnection()` predates this PR, but it becomes a functional problem now that authenticated-download headers are relied on.
### Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/net/URLDownload.java[334-407]
- jabgui/src/main/java/org/jabref/gui/linkedfile/DownloadLinkedFileAction.java[129-137]
- jabgui/src/main/java/org/jabref/gui/linkedfile/DownloadLinkedFileAction.java[296-320]
### Suggested approach
1. Update redirect handling in `URLDownload.openConnection()` to preserve headers/parameters when following redirects. Options:
- Reuse the same `URLDownload` instance by updating its URL (requires refactor), or
- Create a new `URLDownload(newUrl)` and copy the existing `parameters` entries into it before opening the connection.
2. Add/adjust tests to cover redirect behavior with custom headers (can be a unit test around `URLDownload` that simulates a redirect and asserts headers applied on subsequent connection).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new CHANGELOG entry uses developer-centric wording (fulltext fetcher) instead of end-user
focused language. This reduces clarity for average users reading release notes.

Code

CHANGELOG.md[14]

+- We added a fulltext fetcher for Wiley journals using the Wiley TDM API. [#13404](https://github.com/JabRef/jabref/issues/13404)

Evidence

PR Compliance ID 32 requires CHANGELOG entries to be end-user focused. The added line describes an
implementation detail (fulltext fetcher) rather than user-facing behavior.

AGENTS.md
CHANGELOG.md[14-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CHANGELOG entry is phrased in developer-centric terms ("fulltext fetcher") instead of describing the user-facing benefit.
## Issue Context
CHANGELOG entries should be understandable to average users and focus on what changed for them.
## Fix Focus Areas
- CHANGELOG.md[14-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

WileyFetcher builds the TDM API URL by concatenating the raw DOI string into the path, which can
create an invalid URL for DOIs containing characters not accepted by java.net.URI. This causes
URLUtil.create() to throw and the fetcher to fail (returning empty) for otherwise valid entries.

Code

jablib/src/main/java/org/jabref/logic/importer/fetcher/WileyFetcher.java[R44-50]

+        Optional<DOI> doi = entry.getField(StandardField.DOI).flatMap(DOI::parse);
+        if (doi.isEmpty()) {
+            return Optional.empty();
+        }
+
+        return Optional.of(URLUtil.create(TDM_API_URL + doi.get().asString()));
+    }

Evidence

WileyFetcher constructs the URL as TDM_API_URL + doi.asString() and passes it to URLUtil.create,
which uses new URI(trimmedUrl) and rejects invalid URI characters. Elsewhere in the codebase, DOIs
are URL-encoded when inserted into URLs (e.g., Crossref/DOI agency lookup), indicating encoding is
expected for robustness.

jablib/src/main/java/org/jabref/logic/importer/fetcher/WileyFetcher.java[37-50]
jablib/src/main/java/org/jabref/logic/util/URLUtil.java[97-124]
jablib/src/main/java/org/jabref/logic/importer/fetcher/DoiFetcher.java[222-228]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`WileyFetcher` constructs a URL by concatenating the raw DOI into the request path. Some DOI strings can contain characters that must be percent-encoded for a valid URI, causing `URLUtil.create(...)` to throw and the Wiley fetch to fail.
### Issue Context
`URLUtil.create` is strict and uses `java.net.URI` parsing. Other fetchers encode DOI strings when embedding them into URLs.
### Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/importer/fetcher/WileyFetcher.java[37-50]
### Suggested approach
- Build the Wiley TDM URL using proper path-segment encoding.
- Prefer constructing via `URIBuilder` and appending DOI path segments (split on `/`) to preserve slashes while encoding unsafe characters in each segment.
- Alternatively, percent-encode each path segment of the DOI and join with `/`.
- Add a unit test using a DOI containing characters requiring encoding (e.g., parentheses or other reserved characters) to assert `findFullText` returns a valid URL instead of throwing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools