Bug Bounty Hunting — Complete Guide (Part-93)

The Downlink HTTP request header is an experimental Client Hint that tells the server the approximate bandwidth (in Mbps) of the user’s internet connection. Servers can use this information to optimize content delivery, for example, by sending smaller images or lower-quality video to users on slower connections.

Because Downlink could be used for fingerprinting, the reported values are intentionally rounded to the nearest 0.25 Mbps. Before a browser sends the Downlink header, the server must first opt-in by sending the Accept-CH response header with Downlink included. This signals to the browser that the server wants to receive this information.

After opting in, the server might receive a Downlink header in subsequent requests, such as Downlink: 1.7 (meaning approximately 1.7 Mbps).

While the Vary header is often used to tell caches that responses might differ based on a given header, it’s generally recommended not to include Downlink in the Vary header. This is because the downlink speed can change frequently, making resources effectively uncacheable if Downlink is included in Vary.

Currently, browser support for the Downlink header is limited and considered experimental. You should check the browser compatibility table before using it in a production environment.

The DPR (Device Pixel Ratio) HTTP request header was a Client Hint used to tell the server the ratio between physical pixels and CSS pixels on the user’s device. This information was helpful for serving appropriately sized images, similar to how the srcset attribute with x descriptors works in HTML.

Important: The DPR header is now deprecated and non-standard. It has been removed from the Client Hints specification. You should not use it in new projects. The recommended replacement is Sec-CH-DPR (Responsive Image Client Hints).

If a server did use the DPR header (in older implementations), it needed to first opt-in by sending the Accept-CH response header with DPR. Then, the client might send the DPR header (e.g., DPR: 2.0). If the request was for an image, the server had to respond with the Content-DPR header, especially if it differed from the client’s DPR value. The client was then expected to use the Content-DPR value for layout.

Because the server response could vary based on the DPR value, the Vary header should also have included DPR for proper caching.

Although some browsers might still support the DPR header for compatibility reasons, it’s crucial to migrate to the newer Sec-CH-DPR if you need this functionality. Avoid using DPR in any new code.