헤더 페이지 캐싱

아래 웹 사이트에서 아래 헤더를 사용하고 있지만 문제가 있습니다. 내가 처음으로 내 사이트를 방문 할 때 내 ACP 링크를 볼 수 없습니다. 등록 된 회원 만 만들 수있는 정보가 데이터베이스에 있지만 인스턴스가 아닌 사용자가 로그인 한 상태에서 양식이 여전히로드되어있어 member_id 필드가 0 인 정보가 생성되는 경우도 있습니다.헤더 페이지 캐싱

문제가 있다고 생각합니다. 캐시 된 파일이 프록시 캐시에 너무 오래 머물러 있다는 것입니다. 아마도 내가 사용하고있는 캐싱 기술을 놓친 것이거나 오해했을 것입니다.

누구든지 제공 할 수있는 조언을 주시면 감사하겠습니다. 내가 주로 보는 사람의 브라우저에서 작동 할 수있는 뒤로 버튼을 얻으려고

 if ($currentMember->isLoggedIn()) { 
    $this->cachePermission = 'private'; 
    } else { 
    $this->cachePermission = 'public'; 
    } 
    $this->tru->header->set('Pragma', array(
    $this->cachePermission 
)); 
    $this->tru->header->set('Cache-Control', array(
    $this->cachePermission, 
    'no-cache', 
    'max-age=300', 
    's-maxage=300', 
    'must-revalidate' 
));

업데이트. 나는 그 외의 다른 캐싱을 원하지 않는다.

출처

2009-10-30 Webnet

사용자가 로그온했는지 여부에 따라 페이지가 변경되는 경우 페이지를 캐시하지 않을 것을 권장합니다. 그건 너무 극단적 있다면

Cache-Control: no-store, must-revalidate 
Expires: 0

, 나는 적어도 항상 Cache-Control: private을 사용하는 것이 좋습니다 결코이 프록시 캐시에 저장 될 수 없을 것입니다. 내 경험에 의하면 프록시를 허용하면 다른 사용자가 다른 것을 볼 때 문제가 발생합니다.

업데이트 : 당신이 모든 주요 브라우저에서 동일하게 작동하려면 그런 중간 어려울 수 있습니다 찾아 내 경험에

. 그냥 Cache-Control: private, must-revalidate으로 시작하여 거기에서부터 시도해보십시오.

하는 사용자가 로그인 한 페이지의 상태를 기반으로 ETag header을 사용하고 도움이 될 수 있습니다. 헤더가 추가되면, pecl_http는 몇 가지 유용한 기능을 제공 http_cache_etag() 같은 브라우저에 304 없음/수정 응답을 보내는 또 한가지 따라서 캐시에서로드하는 것이 좋습니다.

출처

2009-10-30 03:49:08 Jason

페이지의 헤더에는 로그인 한 모든 기능을 가진 네트워크 바가 있습니다. 따라서 사이트의 모든 페이지는 사용자가 로그인했는지 여부를 유지합니다. 사용자가 캐시를로드하기 위해 브라우저에서 뒤로 또는 앞으로 움직일 때 정말로 필요합니다. – Webnet

헤더를 개인/필수적으로 다시 유효성을 검사하여 제안한대로 조정했으며 그 작동 방식을 살펴 보겠습니다. – Webnet

잘 작동하지 않는 것 같습니다. 나는 무엇이 일어나고 있는지를 결정할 수 없다. 처음 페이지를 방문 할 때마다 적절한 사용자 이름을 가지고 있으므로 로그인 정보가 제대로 감지됩니다. 로그 아웃 옵션과 함께 "내 계정"링크가 표시됩니다. 그러나 내 사이트의 작성자는 초기 페이지가 표시된 후에 저자 CP 링크 만 볼 수 있습니다. – Webnet

FireFox가 캐싱에 매우 공격적이라고 생각했습니다. URI에 인위적인 쿼리 문자열을 입력하면 새로운 결과를 얻을 때 이런 일이 벌어지고 있음을 알 수 있습니다.

?asdf=1

브라우저의 광기를 진단 할 때 종종 끝까지 압도합니다.

출처

2009-10-30 05:43:56

헤더 페이지 캐싱

답변

관련 문제