Django-compressor: CACHE의 압축 파일용 404

압축기를 로컬에서 활성화하면 완벽하게 작동합니다! CACHE 폴더에서 파일을 찾을 수 없는 것은 서버에 있을 뿐이며 다른 모든 것은 찾을 수 없습니다.

Ok 또 다른 발견: 세키자이 + 화이트노이즈 + 컴프레서의 조합으로 인해 문제가 발생하는 것 같습니다. Whitenoise Docs는 "_성능 및 보안상의 이유로 WhiteNoise는 시작 후 새 파일을 확인하지 않습니다(Django DEBUG 모드를 사용하지 않는 한). 따라서 모든 정적 파일은 미리 생성해야 합니다. Django Compressor를 사용하는 경우 이것이 가능합니다. 오프라인 압축 기능을 사용하여 수행됩니다._" 그래서 Sekizai는 사용자가 페이지를 열 때마다 실시간으로 압축합니다(세키자이의 특성으로 인해 오프라인 압축은 사용할 수 없음). Whitenoise는 다시 검색하지 않으므로 파일이 존재하지 않는다고 가정합니다. 페이지를 열고 파일이 생성된 후 Django를 다시 시작하면 작동합니다. 그러나 다른 페이지로 이동하면 동일한 프로세스를 다시 수행해야 합니다(페이지를 열고 다시 시작). 그런 다음 제대로 찾습니다 ...

문제를 해결하는 방법에 대한 아이디어가 있습니까? 다음 테스트는 압축 후처리기와 함께 세키자이를 사용하지 않는 것이지만 세키자이 및 실시간 정적 요청과 함께 작동하는 솔루션을 원합니다.

그래서 whitenoise.django.DjangoWhiteNoise 을 수정하고 변경했습니다.

    self.autorefresh = settings.DEBUG
    self.use_finders = settings.DEBUG

에게

    self.autorefresh = True
    self.use_finders = True

이제 작동합니다. 성능 문제를 무시하고(아직 눈치채지 못한 반면에 Google Page Speed ​​Insight는 자동 새로 고침이 활성화된 상태에서 한 가지 더 포인트를 줍니다..) 보안 문제는 무엇입니까? 나는 그것을 피할 수 있습니까? Whitenoise가 실시간으로 생성된 정적(예: django-compressor CACHE)도 처리할 수 있다면 놀랍습니다.

내 입력이 다른 사람이 이것을 발견하는 데 도움이 되길 바랍니다.

안녕,

이것은 압축기 문제가 아닙니다. 이것은 stackoverflow 또는 이와 유사한 것(또는 아마도 whitenoise 지원 포럼)에 속합니다.

그래, 나는 그 결론에 도달했다 :) 화이트노이즈에서 사람들에게 물어볼 것이다. 감사 해요

@oesah , 감사합니다. 나는 똑같은 문제가 있습니다. 나는 이것이 압축기 문제가 아니며 이 스레드가 이제 닫혔다는 것을 알고 있습니다. 그러나 화이트노이즈에 대한 이 토론을 시작했다면 링크를 게시할 수 있습니다. 나는 이 문제를 해결하기 위해 몇 시간을 보냈고 이 스레드는 생명의 은인이었습니다!