Web Clipper never pairs on Linux: file-gateway probe accepts only HTTP 301, but the gateway returns 307

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing issues and didn't find any that were similar
• I have considered creating a pull request with fixes instead of a bug report and want to proceed

Current Behavior

The Anytype Web Clipper extension cannot pair with the desktop app. Clicking the extension shows "To save in Anytype you need to Pair with the app" with a "Pair with app" button, and under it "Automatic pairing failed, please open the app" — while the app is running and open the whole time.

The cause is in go/nativeMessagingHost.go. The host discovers the app's ports with lsof, then probes each one to identify the gRPC-Web server and the file gateway. It requires BOTH before it reports success. isFileGateway() accepts only HTTP 301:

// should return 301 redirect Location: /file/
if resp.StatusCode == 301 {
    return true, err
}
return false, err

The gateway in 0.56.5 answers with 307, not 301:

$ curl -i http://127.0.0.1:47800/file
HTTP/1.1 307 Temporary Redirect
Location: /file/

So the redirect is exactly the one the comment describes — only the status code differs. The probe returns false, the gateway port stays empty, and detection fails as a whole even though the gRPC-Web port was found correctly.

From the host's own trace log (/tmp/anytype-nmh.log), on every attempt:

TRACE: nativeMessagingHost.go:279: can't detect ports. pid: 924486; grpc: '32809';
  gateway: ''; error: [ ... ]
TRACE: nativeMessagingHost.go:286: ports no able to detect for 1 pids

Note grpc: '32809' found, gateway: '' empty.

There is no user-side workaround: the check is compiled into the shipped nativeMessagingHost binary.

Expected Behavior

The file gateway is detected, port discovery succeeds, and the extension pairs with the running app.

A 307 to /file/ is the same redirect the code is looking for. Accepting the redirect family (301/302/307/308) — or simply checking that Location is /file/ — would fix it and be robust against this drifting again.

Steps To Reproduce

1. Install the Anytype desktop app 0.56.5 on Linux (.deb) and open a vault.
2. Install the Anytype Web Clipper extension 0.0.8 in Chrome. (If Chrome was already running when the app first wrote its native-messaging manifest, fully quit and reopen Chrome so the manifest is picked up — otherwise you hit a different, unrelated failure first.)
3. Click the extension icon on any page.

Result: "To save in Anytype you need to Pair with the app", then "Automatic pairing failed, please open the app" — with the app running.

To see the cause directly:

# the gateway is up and redirecting, but with 307
curl -i http://127.0.0.1:<gateway-port>/file

# the host's own log shows grpc found, gateway empty
tail /tmp/anytype-nmh.log

Find the ports the host would find with the same command it uses:

lsof -i -P -n | grep LISTEN | grep "anytype"

Environment

- OS: Ubuntu 24.04.4 LTS, GNOME/Wayland, x86_64
- Version: Anytype desktop 0.56.5 (Release channel, .deb)
- Extension: Anytype Web Clipper 0.0.8
- Browser: Google Chrome 152.0.7977.64 (.deb, not snap/flatpak)
- Network mode: Local-only
- lsof: installed (the discovery command works and returns the app's ports)

Anything else?

Ruled out

• Native messaging plumbing is fine: the manifests exist for Chrome/Chromium/Brave/ Firefox, the host binary is present and executable, the manifest's allowed_origins names the installed extension ID, and the host process starts and receives messages (its log shows Message received: getPorts and launchApp).
• lsof is installed, and the exact discovery command the host runs returns the app's listening ports.
• The app is running throughout; launchApp is also received and acted on.
• Chrome was fully restarted after the manifest was written.

Where it goes wrong, precisely

go/nativeMessagingHost.go, isFileGateway() — the resp.StatusCode == 301 check. The comment above it already describes the intended behaviour correctly ("should return 301 redirect Location: /file/"); the server now satisfies the redirect but with 307.

Suggested fix

Accept the redirect family rather than one code:

if resp.StatusCode >= 301 && resp.StatusCode <= 308 { ... }

or assert on the Location header instead of the status code.

I am happy to test a build.