고딩 ai scientist

추가적으로 HTML Form 전송에서 파일 같은 것을 전송할 때는 인코딩 타입을 multipart/form-data로 해야합니다. 위를 보면 useranme, age뿐만 아니라 바이트로 되어있는 파일까지 같이 전송해야합니다. 이럴 때는, 위처럼 HTTP 메시지에서 Content-Type가 multipart/form-data로 들어가야합니다. 그리고 boundary라는 것도 들어가줘야합니다. 웹 브라우저에서 자동으로 만들어줍니다. 그리고 -----XXX처럼 경계로 잘라줍니다. HTML Form 데이터 전송 정리 - HTML Form submit시 POST 전송 - 예) 회원 가입, 상품 주문, 데이터 변경 - Content-Type: application/x-www-form-urlencoded 사용 - f..

Cache-Control 확실한 캐시 무효화 응답 - Cache-Control: no-cache, no-store, must-revalidate - Pragma: no-cache - HTTP 1.0 하위 호환 만약 이 페이지가 캐시가 되면 안된다 하시면 위에 것을 넣어주시면 됩니다. 확실히 캐시를 우회하려면, Cache-Control: no-cache, no-store, must-revalidate를 넣어주셔야합니다. 그 다음에 HTTP 1.0에서 혹시 뭔 요청이 온다면 Pragma: no-cache를 넣어주시면 됩니다. 예) 사용자의 통장 장고 Cache-Control 캐시 지시어(directives) - 확실한 캐시 무효화 - Cache-Control: no-cache - 데이터는 캐시해도 되지만, ..

캐시 제어 헤더 - Cache-Control: 캐시 제어 - Pragma: 캐시 제어(하위 호환) - Expires: 캐시 유효 기간(하위 호환) 캐시는 일단 캐시 제어와 관련된 헤더들이 있습니다. 그게 이제 Cache-Control이란 Pragma랑 Expires가 있는데요. 제일 먼저 가장 중요한 Cache-Control에 대해서 말하기전에 요즘은 Pragma랑 Expires는 하위 호환에만 사용하고 Cache-Control로다 다 제어 할 수 있습니다. Cache-Control 캐시 지시어(directives) - Cache-Control: max-age - 캐시 유효 기간, 초 단위 - Cache-Control: no-cache - 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고..

쿠키 - 예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure - 사용처 - 사용자 로그인 세션 관리 - 광고 정보 트래킹 - 쿠키 정보는 항상 서버에 전송됨 - 네트워크 트래픽 추가 모집 - 최소한의 정보만 사용(세션 id, 인증 토큰) - 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage) 참고 - 주의! - 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등) 쿠키 - 생명주기 Expires, max-age - Set-Cookie: expires = Sat, 2..

프록시 캐시 origin 서버가 뭐냐면 진짜 서버를 나타내는데요. 만약 한국에 있는 여러 클라이언트가 미국에 있는 서버에 접근을 해줘요. 원소스가 있는 원 서버에가 미국에 있으니까 웹 브라우저에서 미국까지 가는데 시간이 오래 걸리겠죠. 대략 500ms 걸린다고 가정을 했을 때, 사람들이 이미지 하나를 다운 받으려고 전부 500ms를 기다려야겠죠. 그래서 프록시 캐시라는 서버를 도입해줍니다. 이것은 뭐냐면 미국에 있는 원 서버 입장에서는 이렇게 한국에 있는 사용자들이 접속해주려면 시간이 오래 걸립니다. 그래서 한국 어딘가에다가 프록시 캐시 서버를 넣어 놓고 DNS 요청을 할 때, 조작을 해가지고 요청이 오면 미국에 있는 원 서버에 직접 접근하지 못하게하고 프록시 캐시 서버를 거쳐서 오케 만듭니다. 그렇게 ..

검증 헤더와 조건부 요청 - 검증 헤더 - 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 - Last-Modified, ETag - 조건부 요청 헤더 - 검증 헤더로 조건에 따른 분기 - If-Modified-Since: Last-Modified 사용 - If-None-Match: ETag 사용 - 조건이 만족하면 200 OK - 조건이 만족하지 않으면 304 Not Modified If-Modified-Since는 Last-Modified랑 같이 사용하고 If-None-Match는 ETag랑 같이 사용합니다. 조건이 만족하면 200 OK를 보내주고 조건이 만족하지 않으면 304 Not Modified를 보내줍니다. 검증 헤더와 조건부 요청 예시 - If-Modified-Since: 이후에 데이터가..

캐시 시간 초과 - 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두가지 상황이 나타난다. 캐시 시간 초과 - 캐시 만료후에도 서버에서 데이터를 변경하지 않는다. - 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다. - 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요 캐시가 만료되서 클라이언트에서 서버로 다시 요청했는데 알고보니까 서버에서 데이터를 안 바꾼겁니다. 여기서 잘 생각해보면 데이터를 완전히 전송하는 대신에 저장해 두었던 로컬 캐시를 재사용할 수 있습니다.왜냐하면 데이터가 안 변했기 때문입니다. 그런데 클라이언트에 있는 이 캐시 데이터랑 서버에 있는 캐시 데이터가 안 바꼈다는 사실을 확인할 수 있는 방법이 필요합니다. 그래서 ..

캐시 기본 동작 여러분이 웹 브라우저에서 star.jpg라는 것을 요청한다고 했을 때, 그러면 서버에서 별과 관련된 그림을 내주는거죠. 그래서 star.jpg를 딱 요청하면, 서버에서 응답을 내려주겠죠. 그런데 이렇게 가정을 해줄거에요. 응답 HTTP를 보면 헤더가 있고 실제 이미지와 관련된 어떤 바이트 코드들이 있습니다. 그렇다고 가정을 할 때, 이미지가 대략 HTTP 헤더에 관련된 용량이 한 0.1M 실제 이 이미지에 해당하는 바디는 1.0M로 총 1.1 네트워크가 차지하면서 보내게 됩니다. 그러면 웹 브라우저에서 아래처럼 star.jpg가 표시가 되겠죠. 캐시가 없을 때 똑같은 요청을 한번 더 해주면, 서버에서는 똑같이 요청을 받아서 응답을 내려주는데 헤더랑 바디를 다시 만들어서 1.1M의 용량인 ..

원래 쿠키에 관해서 블로그를 다 작성했었는데 이 tistory 녀석이 임시저장을 그전에 작성한 게시글을 임시저장해버려서 이 글을 날려버리게 되어서 다시 쿠키에 관해서 작성을하게 됩니다. 다시 작성하는 이유로 내용이 미흡할 수 있습니다. 죄송합니다! 쿠키 - Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답) - Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달 쿠키 미사용 예를 들어서 여러분이 웹 브라우저에서 /welcome이라는 페이지에 접근을합니다. 그러면 서버에서는 안녕하세요. 손님이라고 응답을해주겠죠. 그런데 만약 사용자가 user 정보랑 password 정보를 POST 메세지로 보내서 로그인을한다고 가정할 경우 서버에서는 홍길동님이 로그인했습니다라고..

인증 인증과 관련된 헤더 - Authorization: 클라이언트 인증 정보를 서버에 전달 - WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의 Authorization 클라이언트 인증 정보를 서버에 전달 - Authorization: Basic xxxxxxxxxxxxxx 인증에는 여러가지 메커니즘이 있습니다. 그것마다 들어가는 Value는 완전히 다릅니다. HTTP와 관련된 Authorization 헤더는 어떤 인증 메커니즘인지 상관없이 일단 헤더를 제공하는겁니다. 그리고 여기에 인증과 관련된 값을 넣어주시면 됩니다. WWW-Authenticate 리소스 접근시 필요한 인증 방법 정의 - 리소스 접근시 필요한 인증 방법 정의 - 401 Unauthorized 응답과 함께 사용 - 4..