[TIL]server sprint Index

• options : 클라이언트가 이용가능한 통신옵션에 대한 정보를 서버가 보내도록 요청.
  그러므로 이에 대한 응답은, '클라이언트가 -> 서버에 어떻게 접속할지'에 대한 세부내용을 알려주는 헤더를 포함한다.
  

3) 안전하고 멱등한 메소드

3-1)안전한 메소드 : 서버의 관리자가, 클라리언트에게 쉽게 허용하는 메소드.
ex) get,head,option,trace
3-2)불안전한 메소드 : 서버에게 데이터전달 또는 상태를 변하게하는 메소드.
ex) post,put,delete
3-3)멱등한 메소드 : 동일한 메소드를 수없이 호출해도,한번만 요청한것과 같은 결과인 메소드.
❗post를 제외한 http의 모든 메소드가 멱등한 성질을 지님❗

- http 상태코드, 이유 구문

: 세자리로 구성되며, 첫째 자리가 특수한 의미를 갖음.
각 그룹에서 yy가 00인 코드는, 그 그룹의 기본적인, 일반적인 상태를 나타낸다.
만약 서버가 404라는 상태코드를 보냈지만, 클라이언트가 그걸 이해를 못한다면(?) 일반적인 400이라는
상태코드를 다시 보내줄것이다.

1. 상태코드 형식: 1yy / 의미: 정보제공메시지 / 설명: 일반적인 정보 제공. 요청의 성공,실패 표시 x.
2. 상태코드 형식: 2yy / 의미: 성공 / 설명: 서버가 메소드를 받았고 해석했으며, 정상적으로 수행한다는의미.
3. 상태코드 형식: 3yy / 의미: 리다이렉션 / 설명: 성공적으로 작업을 마치기 전, 추가작업이 필요하다.
4. 상태코드 형식: 4yy / 의미: 클라이언트 에러 / 설명: 요청이 잘못되었다. or 구문 오류 발생 or
   기타 클라이언트 오류 발생해 수행 못한다..
5. 상태코드 형식: 5yy / 의미: 서버 에러 / 설명: 요청은 유효하나, 서버자체의 문제때문에 수행 못한다..

- http 공통 헤더 : 요청과 응답에 모두 사용되는 헤더.

• Date : http메시지가 만들어진 시각.
• COnnection : 현재 코드스테이츠에서도 그렇고 http/1.1을 사용하고있음. 기본적으로 keep-alive상태.
• Cache-Control
• Content-Length : 본문 크기를 바이트단위로 표시해줌.
• Content-type : 컨텐츠타입, 문자열 인코딩 명시가능.
  *만약 프론트엔드에서 서버로 보낸다면,
  text/html대신, www-url-form-encoded or multipart/form-data 등등이 될것임.
  .
  .
  .

- http 요청 헤더

• host : 서버의 포트 포함 도메인 네임. **필수로 하나는 존재해야함!!!
• User-Agent : 어떤 클라이언트를 사용해 요청을 보낸건지 명시.
  ex) User-Agent:Mozila/5.0 (Macintosh; Intel Mac OS X 10_13_5)

  이를 통해, 이 예시는 클라이언트가 맥북 크롬인것을 알수있다.
  물론 헤더는 변경가능하므로 완전히 믿을수는없지만, 대부분 조작안하기때문에

  예를들어 이런걸로 접속자 통계를 낼수있다고한다. 이를 활용해 IE로 접속한사람도 알수있다.
  때문에 IE로 접속한 유저에게 크롬으로 접속해주세요 라는 문구가 뜨는것도
  이를 활용한 것이라고 보면된다.

- 렌더링 엔진?

• 위에서 썼듯이, 얘는 요청받은 콘텐츠, 내용을 브라우저화면에 표시해주는 역할을 한다.
• 플러그인, 브라우저 확장기능을 통해서 PDF와 같은 다른유형도 표시할수있다.

- 렌더링 엔진들

• 파이어폭스, 크롬, 사파리 는 두 종류의 렌더링엔진으로 제작되었다.
  ex) 파이어폭스: 모질라에서 직접만든 게코(Gecko)엔진, 사파리와 크롬: 웹킷(Webkit)엔진

  **웹킷엔진: 최초 리눅스 플랫폼에서 동작하기위해 제작된 오픈소스엔진.

  애플이 맥과 윈도우즈에서 사파리브라우저를 지원하기위해 수정을 하였음.

- 렌더링 엔진의 동작과정

보통 문서는 8kb 단위로 전송된다.

1. DOM트리 구축을 위한 html파싱!
   : (1-1)html문서를 파싱하고, '콘텐츠트리'내부에서 태그를 DOM노드로 변환시킨다.
   (1-2)외부 CSS파일과 함께 포함된 스타일요소들까지 파싱한다. 그리고 이때 '렌더트리'가 생성된다.

2. 렌더 트리 구축
   : 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고있다고 한다. 정해진 순서대로?
   화면에 표시된다고 한다... 자세히 지금은 알 필요 없을듯..

3. 렌더 트리 배치

4. 렌더 트리 그리기

browser security

브라우저에서 js로 할수있는것들

1. ajax call을 해서 api를 호출할수있다.
2. 다이나믹하게 dom을 제어할수있다.
3. 인증정보를 브라우저에 저장할수있다.
4. 인증정보를 불러올수있다.

브라우저는 csrf와 xss공격을 받을수있다.

xss: 클라이언트가 서버를 신뢰하기떄문에 발생하는 이슈
예) 서버에 메세지 요청 _> 메세지 응답 -> 응답받은 메세지 돔 반영 이 일반적인 메세지 방식인데
해킹자가 script태그로 감싼 에러코드를 여기에 메세지 text로 넣어서 이상한행동을 만든는것.

csrf: 서버는 인증정보를 갖고오먄 믿는다.
사용자는 인증정보를 가진채로 해커의 링크를 누르면,
해커가 인증정보르 ㄹ가로채서 서버에 요청을 보내버린다..

xss와 csrf는어떻게 막을수있을지를 셍각해보는게 좋다..

아직 유효한 xss방법을 알고있다면, 서버에 공격을 시도해보라.. 이번 스프린트에서!

cors : Cross-Origin resource sharing의 약자로, 도메인 또는 포트가 다른 서버의 자원을 요청하는 메커니즘.
이때 요청을 할 때에는 cross-origin HTTP에 의해 요청된다.
예를들어 http://domain-a.com으로부터 전송되는 html페이지가 </ img>src속성을 통해
XMLHttpRequest를 사용하여
http://domain-a.com/image.jpg를 요청하는경우가 있다.
오느랄 많은 웹페이지들은,
css 스타일시트,이미지 그리고 스크립트와 같은 리소스들을 각각의 출처로부터 읽어온다.

하지만 **동일 출처 정책(same-origin policy)때문에 cors같은 상황이발생시
외부서버에 요청한 데이터를 브라우저에서 보안목적으로 차단한다.

그로인해 정상적으로 데이터를 받을수없게 된다.
XMLHttpRequest, fetch API는 이 동일출처정책을 따르며,
이 api들을 사용하는 웹애플리케이션은 자신의 출처와 동일한 리소스만 불러올수있으며,
다른 출처의 리소스들을 불러오려면
그 출처에서 올바른 cors헤더를 포함한 응답을 response해야한다.

• preflight request
  : 실질적인 요청 전에 option메소드를 통해 발생한다.
  실제 요청이 안전한지 서버가 미리 파악할수있도록 하는 수단이다.
  그리고 모든 cross origin요청이 이걸 발생시키는것이 아니다.
  심플 리퀘스트를 실행하지못하면 프리플라이트가 실행된다.

**동일출처정책: 불러온 문서나 스크립트가, 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안방식임. 이것은 잠재적 악성문서를 격리한다.