Es stellte sich heraus, dass es eine Web-API-Sache war. Ich hatte die Tatsache übersehen, dass im Antwort-Header eindeutig angegeben wurde, dass das Caching deaktiviert wurde.
Antwort wie in dem Registerkarte Netzwerk von Google Chrome angesehen:
Nach further investigation (und wie im Bild oben zu sehen), Caching wird in Web-API-Controller deaktiviert. Sogar das [OutputCache]
Attribut, das in regulären MVC-Controllern verwendet wird, wird nicht unterstützt.
Zum Glück fand ich diesen Blog: http://www.strathweb.com/2012/05/output-caching-in-asp-net-web-api/
, die mich zu diesen beiden Lösungen führen:
ich mit CacheOutput beschlossen gehen, wie es lässt Ich benutze Attribute wie:
[CacheOutputUntilToday]
unterstützt Server & clientseitige Zwischenspeicherung.
Oder wenn ich just use client-side caching wollte kann ich so etwas wie:
[CacheOutput(ClientTimeSpan = 100, ServerTimeSpan = 0)]
die ein wenig leichter auf den ersten Blick, dass CacheCow Ansatz schien. Und wenn nötig, später leichter zu refaktorieren.
Jetzt Wünsche mir einen 200 (from cache)
:
Mit einem Refresh mir ein 304 Not Modified
geben:
Problem gelöst! Hoffe das hilft jemand anderem.
Die Standard-No-Cache-Header sind entweder eine ASP.NET- oder eine IIS-Sache, da die selbst gehostete Web-API dies nicht tut. –
Sorry @DarrelMiller nicht sicher, was du meinst. Auf welche Art von Web-API beziehen Sie sich? – GFoley83
Web-API ist ein Framework, das auf einigen Hosts sitzt: Entweder der IIS/ASP.NET-Host, ein WCF-Self-Host oder ein Owin-basierter Host. Die Caching-Header, die Sie standardmäßig einfügen, werden von dem Host, den Sie verwenden, dorthin gestellt, und nicht selbst Web-API. Nicht, dass es irgendetwas für dich ändert, nur ein FYI. –