Skip to content

Provide an includeRequestsWithCredentials option for HttpTransferCache #69623

Description

@abderrahmanebnd

Which @angular/* package(s) are relevant/related to the feature request?

platform-browser

Description

After the security fixes around HttpTransferCache especially for this PR #67964

Today we have:

withHttpTransferCacheOptions({
  includeRequestsWithAuthHeaders: true,
});

which lets usexplicitly opt into caching requests that contain headers like Authorization and Cookie.

However, requests made with:

  withCredentials: true,

are always excluded.

I'm wondering why there isn't a similar opt-in for credentialed requests, for example:

withHttpTransferCacheOptions({
  includeRequestsWithCredentials: true,
});

From my perspective, both approaches can return user-specific data:

  • Authorization header
  • Cookies (withCredentials)

So if a developer explicitly enables includeRequestsWithAuthHeaders, they're already taking responsibility for the security implications. Why not allow the same for cookie-based authentication?

One use case is applications that never cache SSR HTML for authenticated users (for example by sending Cache-Control: no-store). In that setup, the HTML isn't shared between users, so there isn't a risk of another user receiving someone else's TransferState. It would be nice to still benefit from HttpTransferCache and avoid the extra request during hydration.

Is there a specific reason this option doesn't exist? I had be interested also to hear the design decision behind it.

Thank you

Proposed solution

Exposing a separate opt-in for credentialed requests, similar to includeRequestsWithAuthHeaders.

For example:

withHttpTransferCacheOptions({
includeRequestsWithAuthHeaders: true,
includeRequestsWithCredentials: true,
});

Alternatives considered

Currently the only alternative is to manually use TransferState for these requests instead of relying on HttpTransferCache. it can work, but it means duplicating functionality that's already provided by HttpTransferCache and requires custom logic for requests that would otherwise be handled automatically.

Another option is to accept the additional client-side request after hydration, but this removes one of the main benefits of SSR for authenticated pages.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: common/httpIssues related to HTTP and HTTP Clientgemini-triagedLabel noting that an issue has been triaged by gemini

    Fields

    No fields configured for Enhancement.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions