next.js

c4b20045 - [Segment Cache] Detect third-party redirect + static export w/ HEAD request (#85910)

[Segment Cache] Detect third-party redirect + static export w/ HEAD request (#85910) The PR superseds #85903. #81247 was introduced to: - Some CDN/server configuration that performs extra redirections (e.g., Netlify's `_redirects`, Cloudflare Pages w/ `_redirects`/Page Rules, nginx conf on the origin server), we want Next.js can still be able to fetch the RSC payload after redirections. - But there are also cases where the target is not our Next.js app, for which we should not fetch the RSC payload. Thus, a build id check is implemented to ensure the target is our Next.js app. This is done via a range request to check the first 64 bytes of the HTML response, looking for the injected build id. However, as mentioned in #85903, some popular static hosting providers (like Cloudflare Pages and `Render.com`) don't support range requests, and in the worst case, the entire HTML will be returned (which is wasteful). #85903 was an attempt to combat the waste, but it is not ideal: - The client might not save much bandwidth: with a somewhat good Internet connection, the extra HTML can still be returned in one chunk, and in the worst case, the entire HTML is still returned. - This doesn't ease the server loads This PR changes the approach: - We now use the `HEAD` request to detect third-party redirections, which should ease the server loads - We add a check for `1xx`/`4xx`/`5xx` response (can be a WAF returning 403 or a backend server returning 502), where we still bail out - We no longer enforce the "redirection target belongs to our Next.js app" check. We might be storming prefetch requests toward non-Next.js apps. In the future, we might add an option to disable preflight prefetch to combat that. Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com> Co-authored-by: Janka Uryga <lolzatu2@gmail.com>