복습을 위한

쿠키가 무엇인지 예시를 통해알아보자. 일단 쿠키를 미사용하는 경우이다. welcome페이지에 들어가서 홍길동으로 로그인을 했다고 가정을 하자. 서버에서는 로그인했다고 응답을 준다. 그럼 로그인된 html화면이 나올 것이다. 그리고 다시 사용자는 welcome페이지로 들어갔다. 사용자는 안녕하세요 홍길동을 기대했는데 서버에서는 안녕하세요 손님이라고 한다.. 왜냐? 지금 서버는 로그인이후 다시 welcome페이지에 접근했을 때 그 사람이 로그인한 사람인지 아닌사람인지 구별할 수 있는 방법이 없다. 홍길동이 보낸요청인지 아닌지 모른다는 것이다. 이건 http가 무상태 프로토콜이기 때문이다. 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어지고 다시 요청해도 서버는 이전 요청을 기억하지못한다. 클라이언..

html헤더정보는 일반정보말고 특별한 정보들이 있다. Host는 중요한 필수값이다. 하나의 ip주소에 여러도메인이 적용되어있을 때 구분하기 위해 필요하다. 예제를보자 가상호스트라는 개념이 있다. 200.200.200.2이라는 ip가있을 때 이 서버안에 여러개의 애플리케이션이 실제 다른 도메인으로 구동이되어있을 수 있다는 것이다. 그럼 이렇게 요청이 들어왔을 때 어느 도메인으로 요청이 들어왔는지 구분을 할 수가 없다. tcp는 ip로만 통신을 하는데 어떻게 알겠나? 그래서 이렇게 host헤더를 넣어줘야한다. 서버에서는 이제 알아차리고 처리할 수 있다(가상호스팅) allow는 405오류로 서버가 응답하면서 허용가능한 메서드를 클라이언트에게 알려주는 헤더이다. 서버에서 많이 구현되어있지는않다. 참고만하자. 서..

http헤더의 일반정보를 알아보자. From은 잘 사용되지는 않는다. 검색엔진같은 곳에서 내 사이트를 막 크롤링해갈 수도 있다. 그것이 싫다면 그럼 검색엔진 담당자에게 우리사이트오지말아달라고 전달할 수 있는 수단이 필요할 것이다. 그럴 때 유저에이전트의 이메일 정보를 넣어둘 때 사용한다. referer, 이건 정말 많이 사용된다. 현재 요청된 페이지의 이전 웹페이지 주소를 알 수 있다. 유입경로 분석이 가능하다. 데이터분석할 때 많이 사용한다. user agent는 웹브라우저정보이다. 또는 클라이언트 애플리케이션정보라 보면된다. 특정한 어떤 브라우저에서 장애가 발생하는지 파악을 하는데 유용하다. 통계 데이터 분석을 하는데 유용한 정보이기도하다. http요청을 보내면 중간에 여러 프록시, 캐시서버를거친다...

전송방식은 4개로 분류할 수가 있다. 첫번째는 단순전송이다. 압축하지않았을 때 보통쓴다. 콘텐트 길이 값을 알고있을 때 사용한다. 한번에 요청하고 한번에 쭉 받는 것이다. 단순하게. 압축전송은 서버에서 gzip같은걸로 압축을 하는 것이다. 단순전송과 다르게 content encoding을 추가해줘서 무엇으로 압축했는지 클라이언트에게 알려줘야한다. 분할전송은 나눠서 보내는 것이다. 용량이 크다면 한번에 보내기에 시간이 너무 오래걸리는데 분할해서 전송하 먼저 온 것을 바로바로 표현할 수 있다. 참고로 content length를 넣으면안된다. 길이를 예상하기 어려울뿐더러 분할된 chunked마다 바이트정보들, 길이들이 다 들어있기 때문이다. 범위를 지정해서 전송하는 것이다. 용량을 효율적으로 사용할 수 있다..

협상은 쉽게 말해 클라이언트가 서버에게 원하는 표현을 요청하는 것이다. 자연스럽게 요청시에만 사용한다. 서버는 표현데이터를 만들 때 그걸 참고한다. Accept Language를 살펴보자. 적용 전을 살펴보자 예를 들어 우리가 한국어 브라우저를 사용하는데 외국에 있는 event 페이지에 들어간다. 그 페이지가 기본으로는 영어를 지원하고 한국어도 지원한다고 하자. 하지만 그 서버는 클라이언트쪽이 어떤 언어를 원하는지 모른다. 그럼 기본값인 영어에 관련된 내용으로 한국어 브라우져에 응답을 해준다. 이러면 영어가 나오니 우리는 불편하다. 그래서 이런식으로 우리가 선호하는 언어를 서버에게 말해주는거다. 그럼 서버는 기본값이기 영어지만 한국어도 지원하므로 한국어 데이터를 보내준다. 좀 더 복잡한 예시를 보자 해당..

헤더는 startline을 제외하고는 http전송에 필요한 모든 부가정보가 담긴다. 표현은 요청이나 응답에서 전달할 실제 데이터가 담긴다. (메세지 본문) 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. 표현헤더와 표현데이터를 묶어 표현이라고 말한다. 콘텐트 타입은 콘텐트 바디에 들어가는 내용의 타입을 말해준다. html일 수도 있고 json일 수도 있고 image파일일 수도 있다. 표현데이터 인코딩은 표현 데이터를 압축할 때 많이 사용한다. 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가를 하면 읽는 쪽에서 무엇으로 압축되어있는지를 알고 풀어서 활용가능한다.(예 : gzip으로 압축을 했다) 참고 : identity ->압축을 안한다는 뜻 전송코딩을 사용하면 content length를..

400번대와 500번대의 차이는 오류의 원인이다. 400번대는 오류의 원인이 클라이언트에게 있어서 클라이언트쪽에서 요청을 수정을 해야한다.(요청스펙을 잘못맞췄거나 인증이 안됨) 서버에서는 처리할 수가 없다. 백엔드개발는 사전에 미리 차단해서 400오류로 바로 튕겨내야한다. 철저하게 클라이언트 잘못이라고 명확하게 보내줘야한다. 그래야 클라이언트쪽에서 오류를 살펴볼 수 있으니말이다. 403은 인증은 됐지만 인가가 불가할 때 발생하는 오류코드이다. 자주보는코드이다. 서버입장에서는 이런 리소스가없는데 클라이언트에서 요청했을 때 발생한다. 또는 클라이언트가 권한이 부족한 리소스에 접근할 경우 해당 리소스를 숨기고 싶을 때도 404로 처리할 수 있다. 서버 내부 문제는 대부분 500오류를 쓴다. 백엔드에서 발생한 ..

영구리다이렉션과 다르게 검색엔진에서 url을 변경하면안된다. 다음에 어떻게 될 지 모르기 때문이다. 302 303은 비슷한데 실무에선302를 사용한다. 별 문제는 없다. PRG패턴을 알아보자. 상품을 주문하고 주문하기 버튼을 누른다고 하자. 그럼 post메서드로 서버로 내 데이터가 넘어갈 것이다. 자 그런상태에서 결과가 남아있다. 거기서 웹브라우져를 새로고침하면 어떻게 될까? post데이터가 한번 더 들어가서 서버에 중복주문이 들어갈 수도 있다. 요청했던 것을 새로고침해서 새로고침도 post요청이 또 되버리는 것이다, 이것을 해결해야한다.! PRG 사용 전부터 보자. 주문데이터가 요청이 와서 딱 저장이 됐다. 근데 클라이언트에서의 마지막 요청이 무엇이었나? 주문이었다. 실수로 새로고침누르면 마지막 요청을..

여기서 유저 에이전트는 웹브라우져를 말한다. 서버가 '너의 요청을 완료하려면 추가적인 작업이 필요해' 하고 전달하는 코드이다. 리다이렉션 이해 • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) 원래 페이지에서 url이 바뀌었다고 하자. 하지만 원래 사용자들은 원래 url을 치고 들어갈 경우가 많을 것이다. 서버입장에선 그럼 어? 이제 안쓰는 건데 하고 클라이언트의 웹브라우져에게 알려준다. 그럼 웹브라우져가 어300대 코드고 location헤더 필드가 있네? 하고 스스로 url을 바꾸고 새로운 경로로 다시 요청을 한다. 서버가 그리고 다시 200번대 코드를 응답하는 것이다. 리다이렉션의 종류에는 크게 3가지가 있다. 방금 예시를 든 영구 ..

만약 낯선 상태코드를 서버가 반환한다면???????? 그냥 이렇게 이해하자. 상위상태코드로 해석해서 이해하자. 1xx번대(요청이 처리되어 수신중)는 거의 사용하지않는다. 2xx - 성공 차례대로 알아보자 가장 많이 보는 케이스이다. 200ok post요청은 서버에서 리소스를 생성하고 url관리도 서버가 한다는 것을 기억할 것이다. 200번대이므로 요청이 성공한 것은 이미 알거고 그 중 201이니깐 자원이생성됐고 location헤더가 있겠구나를 판단할 수 있다. 202는 잘 사용하진않는다. 204는 웹문서를 편집하다 save버튼을 누를 때를 생각하면 이해하기가 쉽다. 저장버튼을 누른다고 뭘 할 수 있는게 아니다. 우리는 계속 이어서 편집을 할 것이다. 결과내용없어도 메시지를 보고 성공을 인식할 수 있다. ..