AIMED 서버 HTTP 응답 Cache-Control: no-cache 일괄 적용
개요
브라우저 stale 캐시로 인한 "연결 끊김" 재발을 근절하기 위해, AIMED 7개 한선씨 서버의
모든 HTTP
응답 헤더에
Cache-Control: no-cache, no-store, must-revalidate를
Connection: close 바로 앞에 삽입했다. 동일 패턴으로 규칙성 있게 적용.
무엇을 했는지
각 서버의 응답 헤더 문자열 리터럴에서:
- 변경 전:
...\r\nConnection: close\r\n\r\n
- 변경 후:
...\r\nCache-Control: no-cache, no-store, must-revalidate\r\nConnection: close\r\n\r\n
중요: 서버가 AI 백엔드(:9906/:9401)로 보내는
요청 헤더(
POST /chat,
GET /api/verify)는
제외했다(응답이 아니라 클라이언트 요청이므로). core서버의 204 OPTIONS preflight도 제외.
적용 건수 (Cache-Control 추가된 응답 헤더 수)
| 파일 | 디렉토리 | 포트 | 추가 |
|---|
| 분석서버.한선 | crowny-aimed | 9904 | 3 |
| 일톡서버.한선 | crowny-aimed | 9909 | 3 |
| 관리서버.한선 | crowny-aimed | 9905 | 2 |
| core서버.한선 | crowny-aimed | 9912 | 2 |
| 에임드인트라넷.한선 | crowny-enterprise | 9908 | 2 |
| 에임드ERP서버.한선 | crowny-enterprise | 9910 | 6 |
| 통합플랫폼서버.한선 | crowny-enterprise | 9911 | 2 |
(포털서버.한선은 이미 적용되어 스킵)
빌드/재기동
컴파일: hanseonc_high <파일>.한선 > <파일>.toau — 7개 전부 exit=0
주의: 실행 중인 서버는 <파일>.toau 파일명을 사용(<파일>.한선.toau 아님). 정확한 파일명에 출력.
재기동: lsof -ti tcp:<포트> kill -9 → 즉시 crownyc run <파일>.toau nohup. 7개 전부 새 PID로 정상 LISTEN.검증
- 헤더 존재: 7개 포트 전부
curl -D - 결과 Cache-Control: no-cache, no-store, must-revalidate 정확히 1건.
- 정상 200 + 크기 유지: 7개 전부 HTTP 200, 본문 정상(분석44KB/일톡44KB/관리45KB/core41KB/인트라55KB/ERP55KB/플랫폼13KB).
- 백업 diff: 모든 .한선 파일 변경 라인이 Cache-Control 추가만(non-CacheControl-added=0). 기능/레이아웃 무변경 확인.
- 시뮬레이터 회귀: crowny-simulator aimed-work / aimed-erp / aimed-platform / aimed-job 전 스텝 ✓.
(aimed-work, aimed-platform 끝에 뜨는 "시나리오 오류"는 시뮬레이터 하네스의 리포트 집계/파일명(
/포함) 버그로 서버와 무관 — 모든 테스트 스텝은 통과 후 발생)
관련 파일
- /Users/ef/crowny-aimed/{분석서버,일톡서버,관리서버,core서버}.한선 (+.toau, +.bak)
- /Users/ef/crowny-enterprise/{에임드인트라넷,에임드ERP서버,통합플랫폼서버}.한선 (+.toau, +.bak)
잔여 이슈
- 시뮬레이터 aimed-platform 시나리오의 리포트 파일명에
/가 포함되어 ENOENT 발생(하네스 버그). 별도 수정 권장.
- core서버 204 OPTIONS preflight, ERP의 요청 헤더는 의도적으로 no-cache 미적용(응답 아님/preflight).