의미없는 요청 매개 변수를 추가하여 캐시를 피하십시오.

소개

브라우저측에 응답 데이터의 캐쉬가 있으면, 서버측의 수정이 브라우저측에 반영되지 않는 경우가 있습니다.

캐시가 너무 효과적이어서 서버측의 수정을 확인할 수 없다고 할 수 있습니다.

『독습 JavaScript』 제2판의 P353에 캐시를 회피하는 예(의미없는 리퀘스트 파라미터를 추가하는 예)가 소개되고 있었으므로, 그것을 시험해 보고 싶습니다.

이 기사에서는 브라우저 측에서 응답 데이터를 캐시하는지 확인한 다음 의미 없는 요청 매개 변수를 추가할 때 캐시를 피하는지 확인합니다.

덧붙여 PlayFramework의 캐쉬를 소개할 때에는 PlayFramework에서 쿠키를 사용해 보았습니다. 의 코드를 유용합니다.

디렉토리 구조

사용한 디렉토리 구조는 아래의 디렉토리 구조입니다.

.
├── app
│   └── controllers
│       └── Tokyo.scala
├── build.sbt
├── conf
│   ├── application.conf
│   └── routes
└── project
    ├── build.properties
    └── plugins.sbt

파일

먼저 build.sbt를 살펴 보겠습니다. 여기에서는 프로젝트를 설정하고 있습니다.

build.sbt

libraryDependencies += cache
routesGenerator := InjectedRoutesGenerator

lazy val commonSettings = Seq(
  version := "0.1-SNAPSHOT",
  organization := "com.sandbox",
  scalaVersion := "2.11.6"
)

lazy val root = (project in file("."))
  .settings(commonSettings: _*)
  .enablePlugins(PlayScala)

캐시를 사용하기 위해 libraryDependencies += cache 행을 추가했습니다. 또한 DI를 사용하기 위해 routesGenerator := InjectedRoutesGenerator 행을 추가했습니다.

다음으로 plugins.sbt를 살펴 보겠습니다. 여기에서는 플러그인을 지정합니다.

plugins.sbt

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.4.2")

build.properties를 살펴 보겠습니다. 여기서는 sbt 버전을 지정합니다.

build.properties

sbt.version=0.13.8

routes를 살펴 보겠습니다. 여기에서는 요청을 컨트롤러의 동작과 연결합니다.

GET / controllers.Tokyo.user

application.conf를 살펴 보겠습니다. 이 파일이 없으면 런타임 오류가 발생합니다.

application.conf

# conf/application.conf

Tokyo.scala를 살펴 보겠습니다. 여기에서는 컨트롤러를 준비합니다.

Tokyo.scala

package controllers

import play.api.mvc._
import play.api.cache.Cached
import javax.inject.Inject

class Tokyo @Inject() (cached: Cached) extends Controller {
  def user = cached("page") {
    Action { implicit request =>
      Ok(s"cache!")
    }
  }
}

사실 이것은 런타임 오류입니다.
You do not have an implicit Application in scope. If you want to bring the current running Application into context, just add import play.api.Play.current 라는 오류 메시지에 따라 import play.api.Play.current 를 추가하면 런타임 오류를 해결할 수 있습니다.

DI를 사용해 보았을 때 런타임 오류가 발생하지 않았습니다.

캐시할까요?

Play 서버를 시작하려면 다음과 같은 명령줄을 실행합니다.

$ sbt run

그런 다음 브라우저에서 localhost:9000에 액세스합니다. 처음이므로 캐시가 없습니다. 응답 상태는 200입니다.



⌘+R 등으로 다시 로드하면 처음 액세스할 때 응답 데이터를 캐시하므로 응답 상태가 304가 됩니다.

의미없는 요청 매개 변수를 추가 할 때 캐시를 피할 수 있습니까?

의미 없는 요청 매개변수를 추가할 때 캐시를 피하는지 확인합니다.

확인은 간단합니다. 브라우저에서 http://localhost:9000/?fb=tokyo로 이동합니다. 그러면 응답 상태가 200이 됩니다.
http://localhost:9000/?abc=123 라든지 http://localhost:9000/?tw=9ab 라든가, 의미 없는 리퀘스트 파라미터를 추가하면 캐쉬를 회피할 수 있습니다.

요약

Play cache API를 사용하여 캐시를 시도했습니다. 먼저 캐시를 확인하고 의미 없는 요청 매개변수를 추가할 때 캐시를 피하는지 확인했습니다.

여담

실은, 이 기사에서 소개한 방법에서는, 서버측을 수정해 리로드 하면 브라우저측에 수정이 반영됩니다. .

참조 URL

Play Framework의 기본 캐시가 개발 모드에서 즉시 사라지는 것을 해결합니다 : mwSoft blog

ScalaCache

CacheApi - play.api.cache.CacheApi

브라우저 캐시 요약 - Please Sleep