跳到主要内容
版本:7.0.3

HTTP 缓存

Hunyuan 7b 中英对照 HTTP Caching

HTTP缓存可以显著提高Web应用程序的性能。HTTP缓存主要依赖于Cache-Control响应头以及后续的条件请求头,如Last-ModifiedETagCache-Control指示私有缓存(例如浏览器缓存)和公共缓存(例如代理缓存)如何缓存和重用响应内容。ETag头部用于发起条件请求,如果内容未发生变化,这种请求可能会返回304(NOT_MODIFIED)状态码且不包含响应体。可以说ETagLast-Modified头部的更进阶的替代方案。

本节描述了Spring WebFlux中可用的与HTTP缓存相关的选项。

CacheControl

CacheControl 提供了与 Cache-Control 标头相关的配置设置支持,并且在许多地方都可以作为参数被接受:

虽然 RFC 7234 描述了 Cache-Control 响应头所有可能的指令,但 CacheControl 类型的处理方式更侧重于实际使用场景,注重常见情况,如下例所示:

// Cache for an hour - "Cache-Control: max-age=3600"
CacheControl ccCacheOneHour = CacheControl.maxAge(1, TimeUnit.HOURS);

// Prevent caching - "Cache-Control: no-store"
CacheControl ccNoStore = CacheControl.noStore();

// Cache for ten days in public and private caches,
// public caches should not transform the response
// "Cache-Control: max-age=864000, public, no-transform"
CacheControl ccCustom = CacheControl.maxAge(10, TimeUnit.DAYS).noTransform().cachePublic();

控制器

控制器可以明确支持HTTP缓存。我们建议这样做,因为在对资源的lastModifiedETag值进行条件请求头比较之前,需要先计算这些值。如以下示例所示,控制器可以在ResponseEntity中添加ETagCache-Control设置:

@GetMapping("/book/{id}")
public ResponseEntity<Book> showBook(@PathVariable Long id) {

Book book = findBook(id);
String version = book.getVersion();

return ResponseEntity
.ok()
.cacheControl(CacheControl.maxAge(30, TimeUnit.DAYS))
.eTag(version) // lastModified is also available
.body(book);
}

前面的例子中,如果与条件请求头进行比较后表明内容没有变化,则会返回一个304(NOTModified)响应,且响应体为空。否则,会将ETagCache-Control头添加到响应中。

您也可以在控制器中根据条件请求头来进行检查,如下例所示:

@RequestMapping
public String myHandleMethod(ServerWebExchange exchange, Model model) {

long eTag = ... 1

if (exchange.checkNotModified(eTag)) {
return null; 2
}

:model.addAttribute(...); 3
return "myViewName";
}
  • 应用程序特定的计算。

  • 响应状态被设置为304(NOT_MODIFIED,即未修改)。无需进一步处理。

  • 继续请求处理。

有三种方法可以检查基于eTag值、lastModified值或两者的条件请求。对于条件GETHEAD请求,可以将响应设置为304(NOT MODIFIED)。而对于条件POSTPUTDELETE请求,则可以将响应设置为412(PRECONDITION_FAILED),以防止并发修改。

静态资源

为了获得最佳性能,你应该使用Cache-Control和条件响应头部来提供静态资源。请参阅配置静态资源的相关部分。