IIS Module not setting Cache-Control

[Nate Klingenstein]

All,

A client switched from using the now-unsupported ISAPI filter to the IIS module.  Upon doing so, they immediately got tickets from IdP's that were experiencing an influx of replayed AuthnRequests presenting themselves as Stale Requests in the browser.  One reporter mentioned cache-control: no-cache was not being set and blamed that for the replays.

I did some checking around; the Apache module and the ISAPI filter appear to both set the cache-control header to: private,no-store,no-cache,max-age=0.  Other sites running the ISAPI module also found that cache-control was not being set, but with no apparent issues in their deployment.

We ran full Request Tracing on the IIS server using both the filter and the module.  With the filter, we can clearly see cache-control being set.  With the module, we never see an attempt to set it at all.  The below is from a request trace with the filter enabled.

GENERAL_SET_RESPONSE_HEADER {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 4 56 0x0 redacted-WIN10 {80000003-0007-F800-B63F-84710C7967BB} Cache-Control private,no-store,no-cache,max-age=0 false

There is no other module or part of the IIS server that is visibly interfering with the outbound response, and I can find almost no information about this in the Wiki or upgrade notes.

I find the reporter's observation about cache-control plausible, but I would expect much more widespread problems if it were the issue.  Is it intended that no cache-control be set by the module?  Is there some configuration that would cause this to happen?  Has anyone else had issues with this?

Thanks in advance,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id