# Support for
x-ipfs-path headers in IPFS Companion
IPFS Companion can redirect traditional HTTP requests to IPFS if the
x-ipfs-path response header is provided.
IPFS HTTP gateways can return an
x-ipfs-path header with each response. The value of the header is the IPFS path of the returned payload.
The WebExtension API onHeadersReceived can cancel and redirect the HTTP request as soon as the response headers arrive. This means the client can drop the initial request, avoiding duplicate downloads of the content.
Detection of the
x-ipfs-path header can be disabled in the Preferences screen (but is enabled by default).
# Use cases
# Fallback for edge cases where the IPFS path is not present in the URL
A website owner can have the HTTP gateway behind a reverse-proxy, but configure it to expose
/, in which case path-based IPFS detection by IPFS Companion (see onBeforeRequest) won't work.
Thanks to the
x-ipfs-path header, we have a reliable fallback for these configurations.
# Hinting DNSLink lookups
The presence of an
x-ipfs-path header is a clear indicator that a website uses IPFS.
There is a "best-effort" DNSLink policy enabled by default to execute blocking DNS TXT lookups for FQDNs that returned the header.
x-ipfs-path values starting with
/ipns/ will be ignored if DNSLink policy is "off" or the DNS TXT record is missing.
# Other resources
- An overview of the
onHeadersReceivedlisteners can be found in the WebExtensions API: webRequest documentation