Julien Saguet

I'm not a network expert so I don't know if it would be feasible or if it would cover every use case. But anyway, I don't think that the frontend...

I edited the first message to suggest a second approach that would allow more customization for the end user without adding more options to the existing API by exposing the...

Hi @AndrewKushnir, do you have any thoughts on this issue and the related PR please ? It looks like a fairly requested feature based on the reactions and comments and...

@AndrewKushnir Thanks for your reply! I think this approach would definitely solve this issue. We are currently using a map between internal and public domains to implement our own custom...

We're using different domains on server and browser to make our API calls. The consequence is that the transfer cache never reuses our API calls With the previous implementation (`TransferHttpCacheModule`)...

Unfortunately no, I haven't. I had to disable the new http transfer cache with `provideClientHydration(withNoHttpTransferCache())` and continued using `TransferHttpCacheModule` that is based on `HTTP_INTERCEPTORS` token.

I believe the use case of different domains/path between server and browser API calls is not resolved yet. More generally, we're still lacking a way to customize the cache key...

I'm afraid checking against nullish values will not be enough because the url is then checked in `verifyMappedOrigin`. Out of curiosity, is there something preventing you from using your actual...

I'm having issues with the chunk optimizer since version 20.2.0. It seems to be much less effective now that rolldown is used instead of rollup. For example in my app,...