Access-Control-Allow-Origin
요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생한다 이 때 서버에서 응답 메시지 Access-Control-Allow-Origin 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다
Access-Control-Allow-Origin: www.zerocho.com
Access-Control-Allow-Origin: *
만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용할수 있다. 단 그만큼 보안이 취약해진다
Access-Control-Request-Method,
Access-Control-Request-Headers,
Access-Control-Allow-Methods,
Access-Control-Allow-Headers 등이 있습니다. Request랑 Allow에서 Method 단수 복수가 다르다
CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다. 이 때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고, Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다
Allow들은 Request에 대응되는 헤더로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다. Request랑 Allow가 일치하면 CORS 요청이 이루어진다.
Allow
Allow 헤더는 Access-Control-Allow-Methods랑 비슷하지만, CORS 요청 외에도 적용된다는 데에 차이가 있다. 즉 GET www.zerocho.com은 되고, POST www.zerocho.com은 허용하지 않는 경우, 405 Method Not Allowed 에러를 응답하면서 헤더로
Allow: GET
를 같이 보내면 됩니다. GET 요청만 받겠다는 뜻입니다.
Content-Disposition
Content-Disposition: inline
Content-Disposition: attachment; filename='filename.csv'
응답 본문을 브라우저가 어떻게 표시해야 할지 알려주는 헤더 inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드된다
다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있습니다. 파일용 서버인 경우 이 태그를 자주 사용하게 된다.
Location
HTTP/1.1 302 FoundLocation: /
300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더이다
이런 응답이 왔다면 브라우저는 / 주소로 리다이렉트한다
참조 문서 zerocho