잡다한 포스트

1. 협상( 콘텐츠 네고시에이션) 클라이언트가 선호하는 표현 요청 Accept : 클라이언트가 선호하는 미디어 타입 전달 Accept-Charset : 클라이언트가 선호하는 문자 인코딩 Accept-Encoding : 클라이언트가 선호하는 압축 인코딩 Accept-Language : 클라이언트가 선호하는 자연 언어 => 협상헤더는 요청시에만 사용 1.1. 협상과 우선순위1 Quality Values(q) 값 사용 Quality Values(q) 값 사용 0~1, 클수록 높은 우선순위 생략하면 1 Accept-Language : ko-KR,ko;q=0.9,en-US;q=0.8,en;1=0.7 1. ko-KR;q=1 (q생략) 2. ko;q=0.9 3. en-US;q=0.8 4. en;1=0.7 1.2 협상..

우선 파일을 주기적으로 삭제하는 스크립트를 준비한다. find /dir/ -empty -type d -delete -print 위의 스크립트를 /root/test/test.sh 파일에 등록한다. chmod +x test.sh 등록 후에 실행 가능하게 설정을 해줘야 한다. 이제 저 스크립트를 crontab에 등록해야 한다. ################################################################################################ 우선 필자의 경우에는 도커를 사용중에 있어 도커에 접근하는 단계도 추가하겠다. 아래의 명령어로 현재 올려져 있는 도커 리스트를 조회한다. docker ps // 개인정보는 가렸습니다.. 제일 우측의 NAMES 열을 ..

먼저 현재 도커가 올려진 서버에 PUTTY 로 접속을 한다 docker ps => 현재 실행중인 도커 리스트 확인 가능 docker exec -it docker_name /bin/bash => 이 docker_name 안으로 들어가겠단 말 exit => 도커에서 빠져나오기

JAVA 연산자는 외워지는데 이상하게 JSTL 연산자 쓰려고 하면 기억이 안나서 정리한 JSTL 연산자! 자주 쓰는 JAVA 와 비교했다! JAVA JSTL == eq != ne gt = ge && && and and || || or or ! ! not not

표현 헤더의 경우에는 디비에 있는 정보(리소스)를 HTTP 프로토콜로 보낼 떄 이 정보를 나타내는 헤더이다. 회원 리소스를 html소스 표현 또는 json 표현 또는 ...등등 표현 헤더는 전송, 응답 둘다 사용한다. - Content-Type : 표현 데이터의 형식 - Content-Encoding : 표현 데이터의 압축 방식 - Content-Language : 표현 데이터의 자연 언어 - Content-Length : 표현 데이터의 길이 표현 데이터 형식 ( Content-Type) - 미디어 타입, 문자 인코딩 - 예) text/html; charset=utf-8 : HTML application/json : JSON (기본이 UTF-8) image/png : 이미지 표현 데이터 인코딩 ( Con..

HTTP 헤더 필드 : field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) field-name은 대소문자 구분 없음 HTTP 헤더의 용도 HTTP 전송에 필요한 모든 부가정보 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...등 표준 헤더가 너무 많음 필요시 임의의 헤더 추가 가능 helloword : hihi HTTP 헤더 과거 표준(RFC2616) 헤더 분류 General 헤더 : 메시지 전체에 적용되는 정보, 예) Connection : close [요청이든 응답이든 다 들어감] Request 헤더 : 요청정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ...) Respon..

400대랑 500대의 가장 중요한 차이점은 400대는 클라이언트 요청 오류라 아무리 새로고침해도 에러가 고쳐지지 않지만 500대 에러는 서버문제이기 때문에 서버가 복구되거나 디비가 복구되는 경우 반복 요청시 접근 가능할 수 있다. 서버는 의도적으로 500대 에러를 내면 안된다 만약 20세 미만의 회원가입을 받지 않는다고 했을 때 15세가 회원가입을 신청했을 때 500대 에러를 낸다? 절대 안된다. 400대나 200대로 해결을 해야 한다. 다음은 400번대와 500번에 HTTP 상태코드이다. - 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 요청 구문, 메시지 등등 오류 클라이언트는 요청 내용을 다시 검토하고, 보내야함 예) 요청 파라미터가 잘못되거나, AP..

오늘은 HTTP 상태코드의 300번대에 대해 알아보겠다. 보통은 리다이렉션을 요청하는 상태코드이다. 300 번대 결과값이 나오는 요청에는 PRG가 있다. ( PRG란 Post/Redirect/Get 의 앞자리만 따온 것) PRG를 사용해야하는 예시를 하나 들어설명해보겠다. 만약 POST로 주문 후에 웹 브라우저를 새로 고침한다고 생각해보자. 새로고침은 다시 요청을 보내고, 중복주문이 될 수 있다. 이 상황을 단계로 나타내보자. 1단계 : 주문을 클라이언트에서 요청한다. (POST) 2단계 : 서버는 주문데이터를 디비에 저장한다. 3단계 : 디비에 저장후 서버는 클라이언트에 성공 메시지를 응답한다. 4단계 : 결과 화면에서 새로고침을 한다.(POST) 5단계 : 또 다시 요청이 클라이언트에서 서버로 들어간..

HTTP API는 예시를 POST기반과 PUT 기반으로 나누어 들수 있다. POST 기반 API 설계 예시 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE 여기서 URL(members)은 동사가 아닌 자원 그 자체로 설정해야 한다. 위 예씨를 보면 목록과 등록이 같은 URL인데 이것은 GET과 POST의 차이이다. 단순한 조회의 경우에는 GET을 사용하고 데이터를 등록하거나 수정하는 것 등의 경우에는 PATCH, PUT, POST를 적절히 사용하면 된다. 다음은 PUT 기반의 API 설계 예시이다. 파..

1xx : 요청이 수신되어 처리중 2xx : 성공 - 200 OK : 요청 성공 - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 - 022 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 3xx : 리다이렉션 - 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) - 301 : Moved Permanently : 리다이렉트 요청시 요청 메서드가 GET으로 변하고, ,본문이 제거 될 수 있음 ( MAY) - 308 Permanent Redirect : 301과 기능은 같음, 리다이렉트 요청 메서드와 본..