프로덕션 환경으로 푸시하면 Rails가 자산의 다이제스트를 생성하므로 application.js이 application-2695540c610db8087315134277d8afe6.js이됩니다. Managed 파일에 다이제스트/지문이 추가되어 Rails에서 해당 파일을 추적 할 수 있습니다.Rails 에셋이 매니페스트와 일치하지 않는 다이제스트와 함께 요청되면 어떻게됩니까?
제 질문은 : 다른 다이제스트로 저작물을 요청하면 어떻게 될까요?
우리의 앱은 Rails가 모든 애셋을 제공하도록 설정되어 있으며, 모든 애셋을 처리하는 Google의 CDN에 의해 캐싱됩니다. 우리가 관찰 한 바에 따르면 정확한 다이제스트로 요청 된 자산은 즉시 처리되는 반면 다른 기업은 시간이 걸리므로 라이브로 컴파일 될 수 있다고 생각합니다.
다이제스트는 캐싱 문제를 해결하는 데 도움이됩니다. 사용자가 이미 이전에 소화 된 저작물을 요청한 경우 해당 저작물이 컴퓨터에 캐시됩니다. 어떤 이유로 페이지에서 해당 버전의 자산을 호출하려고하면 사용자에게 캐시 된 버전이 제공됩니다. 그렇지 않으면 애셋이 사용자 시스템에 캐시되지 않고 페이지가 페이지를 가져 오려고하면 애셋은 더 이상 존재하지 않으므로 읽을 수 없습니다.
사전 컴파일 된 자산의 전체적인 점은 단지 파일 시스템의 파일이라는 것입니다. 이전 애셋을 삭제하지 않을 경우 (즉, 배포 할 때마다 새 디렉토리를 만들어서) 여전히 존재하며 그 요청은 성공합니다.
이전 애셋을 삭제하면 config.assets.compile이 사용 설정되어 있지 않으면 서버에서 404로 응답합니다. 그러면 자산 파이프 라인이 작동하는 방법은 이 아니라 요청시 자산을 컴파일하는 것입니다. 프로덕션 환경에서는 이 아니고으로 설정해야하며 정적으로 컴파일 된 애셋을 사용해야합니다.
일반적으로 컴파일 된 자산이있는 public 폴더는 예를 들어 symlink를 통해 모든 배포에서 공유되어야하므로 오래된 자산을 요청하는 페이지에서 찾을 수 있습니다.
응답 해 주셔서 감사합니다! 'config.assets.compile'은 false로 설정됩니다 (실제로 설정되지 않았습니다). 우리는 Heroku를 사용하고 있으며 오래된 자산은 보관하지 않습니다. 404는 예상했던 동작이지만, 자산을 컴파일하는 데 너무 오래 걸리고 시간이 초과되기 때문에 확실하게 뭔가를 반환합니다. 가끔은 503입니다. – ben
왜 내가이 동작을보고 있었는지에 대한 대답이 없지만 디버깅하는 동안 스프로킷 2를 사용하고있는 것으로 나타났습니다. 스프로킷 3으로 업그레이드 한 후 사전 컴파일되지 않은 애셋이 올바르게 404를 반환합니다. – ben
내 질문은 사용자가 클라이언트에서 발생하는 것이 아니라 다른 다이제스트로 자산을 요청할 때 Rails 백엔드에서 발생하는 것에 대해 자세히 설명합니다. – ben