Reponse -0616

maven :

중앙저장소에서 다운받은 파일은

1. plugin(환경설정)

2.dependency( 개발)

json: 가벼운 방식의 응답데이터

xml : 무거운방식의 응답데이터

=>만약에 제약조건을 설정해야한다면 json가지고는 안됨 xml스키마나 데피니션구조가 있기에 제약조건 설정가능

 

<response 구조>

ctrl+Shift+t : 인터페이스 찾기 

1. 비동기 요청

2. js :정적요청 

1. HTTP 응답 패키징(HttpServletResponse 캡슐화) 방식

1. Response Line: Protocol/version Status Code

	**Status Code : 요청 처리 성공/ 실패에 대한 상태 코드
		1)100 :ing...Websocket, WebRTC(구글meet, real time process 사용됨. 실시간 양방향)
		2)200 :OK
		3)300 :요청이 처리되기 위해서는 클라이언트의 추가 액션이 필요함.
		  304 :NotModified : cache 연관, 클라이언트가 캐싱한 데이터가 서버에서 변경된 적이 없는 최신 데이터임.
		  302/307 :Moved :location(new address) 헤더와 함게 사용됨. -Redirect.
		4)400 :fail(client side 요청이 잘못됐다.클라이언트가 비정상 코드를 넘기고있음)
		  401 :SC_UNAUTHORIZED(관리자 권한이 없는 사용자가 요청하는경우. 당신은 이권한 사용할 수 없다,권한오류)
		  403 :SC_FORBIDDEN(접근을 막는다. 접근제어 할때 사용,인트라넷에서 주로 사용,권한오류)
		  404 :NotFound(그런 리소스는 없다.URI표현할 수  있는 자원은 없다.url 오류)
		  405 :Method NOT Allowed : method callback 이 구현되지 않은 경우.
		  406 :SC_NOT_ACCEPTABLE:서비스 미디어 타입
		5)500 :fail(server side), 500(Internal server error)

 

두번째 요청때 첫번째 데이터에 활용됐던 캐시데이터를 다시 활용

304: 이미 브라우저가 캐시를 저장해놓은것 ,이미 브라우저가 정적자원을 캐싱

서버까지 갔다와야하니까 브라우저야 이미 넌 갖고있어  알려줌 304가...

 

302/307 : 나 다른자리로 이동했음을 알려줌 즉 새로운 주소에대한정보도 같이 

단비 찾았고 일주일 뒤 자리 바뀜 창규가 받았고 단비는 어디로 옮겨갔음을 알려줘야함

나는 다시 새로운 주소를 찾기위해 요청 보냄  단비를 찾아야지 이게 내가 해야하는 추가 액션 

즉 요청이 하나로끝나는것이 아니라  한쌍으로 발생 

 

100 : 음식만드는데 시간이 오래걸림 이자원을 내보낼때 잠깐만 기다려 음식줄게 하도록

500 : fail(실패 원인 : server side), 500(internal server error)
                    -> 세분화되지 않은 이유는 응답 상태코드로 서버의 정보를 노출하기 않게하기 위해서이다.

1. Line

response.sendError(HttpServletResponse.SC_BAD_REQUEST); 했을때 

요청 검증에서 주로 사용됨.

 

 

---

response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);

검증 통과 후 요청 처리에 문제가 발생시 사용됨

---

response.setStatus(HttpServletResponse.SC_CONTINUE); 했을때

 

요청을 분석도 해야하지만 응답데이터를 만들어내야함 컨텐츠만이 아니라 컨텐츠 구조도 만들어야함

응답,요청의 구조가 중요함

 

2.Response Header  사용  

2. Response Header :서버와 응답에 대한 meta data (name/value)

		1) content mime type 설정 : Content-Type
			-setHeader("Content-Type", "application/json")
			-setContentType(MIME)
			-page 지시자의 contentType 속성(JSP spec)
			
		2) cache control : Cache -Control, Expires [Pragma]
		<a href ="cacheControl.jsp">cacheControl.jsp</a>
		3) auto request :Refresh
		<a href ="refresh.jsp">refresh.jsp</a>
		4) flow control : Location
		<a href ="flowControl.jsp">flowControl.jsp</a>

버퍼 사용하게되면 서버 어딘가에 임시공간잡혀있음 스트림에 바로 기록하지않고 버퍼에 기록함 버퍼가 꽉찬 상태가 되면

버퍼가 한번에 플러쉬됨 근데 기본이 8kb 

1. 전송효율 높아짐

2. 내가 가지고 있는 저장소 이며 내가 제어가능 (삭제도 가능) 버퍼 안의 내용은 임시데이터 언제든지변경 가능한 장점

    존재 (플러쉬 하기 전까지)

setBufferSize로 크기 조정

setChacterEncoding, setContentType : 메타 데이터임

1. request

2.reponse

브라우저가 이 응답데이터 가져가서 html로 할거니 plain이니

응답데이터 자체는 바디가 들어있고 라인과 헤더를 통해 뭘할지가 결정이 됨 

그래서 헤더가 메타 데이터라고 표현했던것임 

---

응답 캐시 제어 헤더

<caheControl.jsp>

	-Pragma (HTTP/1.0)
	-Cache-Control(HTTP/1.1) : 캐시제어 여부, 캐시 데이터의 속성들을 표현하는 지시자.(public,private(비공개),max-age=seconds(언제까지 저장))
	-Expires : 캐시 만료 시점 설정.

서버 기준이 아니라 클라이언트의 기준으로  그러면 둘중에 뭘 사용할까?Pragma (HTTP/1.0),Cache-Control(HTTP/1.1둘다 쓰는게 맞음 

Cache-Control:일주일동안 하고싶어 

Expires : 예를들면 6월20일 오후 4시에 없애라

 

<h4>응답 캐시 제어 헤더</h4>

	<%	
		//캐시를 저장하지 않을때 : no-cache(일단 저장,저장된 데이터 쓰기전에 서버에게 나이거 사용해도 돼?304) , no-store(아예 저장x)
		response.setHeader("Pragma", "no-cache");
		response.addHeader("Pragma", "no-store");
		response.setHeader("Cache-Control", "no-cache");
		response.addHeader("Cache-Control", "no-store");
		response.setDateHeader("Expires", 0);  //과거로 올라가서 저장해 즉 하지말란 소리
	%>

캐시 저장할 수 없음 

---

캐시를 저장할때

<h4>응답 캐시 제어 헤더</h4>
<pre>
	Pragma (HTTP/1.0)
	Cache-Control(HTTP/1.1) : 캐시제어 여부, 캐시 데이터의 속성들을 표현하는 지시자.(public,private(비공개),max-age=seconds(언제까지 저장))
	Expires : 캐시 만료 시점 설정. 
	<%	
		//캐시를 저장하지 않을때 : no-cache(일단 저장,저장된 데이터 쓰기전에 서버에게 나이거 사용해도 돼?304) , no-store(아예 저장x)

		response.addHeader("Cache-Control", "public");
		Calendar cal =Calendar.getInstance();
		cal.add(Calendar.DATE, 2);  //이틀뒤에 이시간
		response.setDateHeader("Expires", cal.getTimeInMillis()); 
	%>
</pre>

 

누구나 쓸 수있도록 캐시 남겨라 

---

번외- 최프때 사용 

---

https://developer.mozilla.org/ko/

MDN Web Docs

 

Cache-Control검색

 

---

auto request :Refresh

1. Refresh 를 이용한 서버사이드 방식의 auto

<refresh.jsp>

=> 실시간이아님 어떻게보면 과거시간임(시간은 흐르고있으므로)

그래서 refresh 헤더 사용

1a 가 되면 의미가 없어짐 

 

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>08/refresh.jsp</title>
</head>
<body>
<h4> Auto request</h4>
<h4> 현재 서버의시간 : <%= new Date() %></h4>
<pre>
	1. Refresh 를 이용한 서버사이드 방식의 auto
	<%
		response.setIntHeader("Refresh", 1);
	%>
	2. 클라이언트 사이드 방식 auto
		1) HTML meta tag
		2) JavaScript 의 scheduling 함수
</pre>
</body>
</html>

=> 단점 : 현재 클라이언트 작업 유지할 수 없음 

2. 클라이언트 사이드 방식 auto

1) HTML meta tag

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="Refresh" content="1"> // 1초마다 시간 바뀜
<meta http-equiv="Refresh" content="3;url=https://www.naver.com">  //3초뒤 네이버로 넘어감
<title>08/refresh.jsp</title>
</head>
<body>
<h4> Auto request</h4>
<h4> 현재 서버의시간 : <%= new Date() %></h4>
<pre>
	1. Refresh 를 이용한 서버사이드 방식의 auto
<%-- 	
 		response.setIntHeader("Refresh", 1);
 --%>
	2. 클라이언트 사이드 방식 auto
		1) HTML meta tag
		2) JavaScript 의 scheduling 함수
</pre>
</body>
</html>

=> 같은 방법임

content="3;url=https://www.naver.com"    :  ;뒤에 추가적인값을 줄 수 있음 

 

---

2) JavaScript 의 scheduling 함수:

 

1. 아무것도 안하다가 특정시점에 수행

2. 일정주기에 맞춰 계속 반복 수행 

 

<script type="text/javascript">
	setTimeout(() => {
		location.reload();
	}, 1000*3);

</script>

 1000*3 3초이후에 딱한번 작업

=> 상태유지 안되고 있음 

즉 위에코드와 같이 똑같은 방법임

---

이번엔다른방법

주기적으로 반복

템플릿 사용 다시확인 -> aj누르고 컨트롤 스페이스 !!

<refresh.jsp>

setInterval(function(){
		$.ajax({
				         url : "getServerTime.jsp",
				         dataType : "json",
				         success : function(resp, status, jqXHR) {
							
							timeArea.html(resp.time);
				         },
				         error : function(jqXHR, status, error) {
				            console.log(jqXHR);
				            console.log(status);
				            console.log(error);

				         }
				      });
			}, 1000);
            });

<getServerTime.jsp>

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="application/json; charset=UTF-8"
    pageEncoding="UTF-8"%>
{
	"time" : "<%=new Date() %>"

}

 

 

---

<script type="text/javascript">
// 	setTimeout(() => {
// 		location.reload();
// 	}, 1000*3);
	let timeArea = $("#timeArea");   //나중에 빠르게 제공하기 위해서 

//	setInterval((function(){
		  $.ajax({
		         url : "getServerTime.jsp",
		         dataType : "json",
		         success : function(resp, status, jqXHR) {
					
					timeArea.html(resp.time);
		         },
		         error : function(jqXHR, status, error) {
		            console.log(jqXHR);
		            console.log(status);
		            console.log(error);

		         }
		      });
//	}, 1000);

</script>

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="application/json; charset=UTF-8"
    pageEncoding="UTF-8"%>
{
	"time" : "<%=new Date() %>"

}
<%
	response.setIntHeader("Refresh", 1);
%>

=>비동기에서 동작이 안되는 헤더도 있다.

 

---

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<script type="text/javascript" src="<%=request.getContextPath()%>/resources/js/jquery-3.6.0.min.js"></script>

<title>08/refresh.jsp</title>
</head>
<body>
<h4> Auto request</h4>
<h4> 현재 서버의시간 : <%= new Date() %></h4>
<h4>비동기 요청으로 갱신되는 시간: <span id ="timeArea"></span> </h4>
<input type="button" value="start" id="start" class="control"/>
<input type="button" value="stop" id="stop" class="control"/>
<pre>
	1. Refresh 를 이용한 서버사이드 방식의 auto
<%-- 	
 		response.setIntHeader("Refresh", 1);
 --%>
	2. 클라이언트 사이드 방식 auto
<!-- 	1) HTML meta tag :<meta http-equiv="Refresh" content="3;url=https://www.naver.com"> -->
		2) JavaScript 의 scheduling 함수:
</pre>
<script type="text/javascript">
// 	setTimeout(() => {
// 		location.reload();
// 	}, 1000*3);
	let timeArea = $("#timeArea");   //나중에 빠르게 제공하기 위해서 
	let jobId =null;
	$(".control").on("click",function(event){
//		this.id 
		let btnId = $(this).prop("id");
		if(btnId =="start"){
			jobId =setInterval(function(){
				  $.ajax({
				         url : "getServerTime.jsp",
				         dataType : "json",
				         success : function(resp, status, jqXHR) {
							
							timeArea.html(resp.time);
				         },
				         error : function(jqXHR, status, error) {
				            console.log(jqXHR);
				            console.log(status);
				            console.log(error);

				         }
				      });
			}, 1000);
		}else{
			clearInterval(jobId);
		}
	});


</script>
</body>
</html>

<getServerTime.jsp>

<%@page import="java.util.Date"%>
<%@ page language="java" contentType="application/json; charset=UTF-8"
    pageEncoding="UTF-8"%>
{
	"time" : "<%=new Date() %>"

}
<%
	response.setIntHeader("Refresh", 1);
%>

---

웹 어플리케이션에서 페이지 이동

1. Request Dispatch (요청 분기)

<부가 설명>

 

1.서버사이드 위임구조 : 이동구조를 클라이언트는 모른다.

응답데이터가b에서만나감

 

2. a와 b가 있어

클->a

a->b에게 요청

a,b합쳐서 나가고 같이 책임지고 있음 => include구조

페이지를 모듈화 할때 include사용 

 

3. 요청이 a로 발생 a에서 클라이언트로 응답데이터감(302코드와 Location포함) 그리고 b셋팅

클라이언트가 새로운 요청 b로 그리고 b에서 응답 

즉 요청 응답 2개씩 발생 => redirect방식 

 

1. 요청을 그대로 

2.요청을 끊어내고 새롭게 요청

 

질문 : 내 정보 20개 보냈는데 3개 검증 통과 못함 17개는 가져가야함 유지한 상태로 보내줘야함

1번의 디스패치 방식

반대로 회원가입 해 20개 검증 끝 가입완료 로그인 페이지로 보내야해 이미 가입처리 끝났자나

처리 끝난 데이터를 남길 필요 x 그래서 리다이렉트 구조사용 2번 방식

 

---

1) forward :Model2 구조에서 활용. request 처리자(Controller)와 response처리자(View)가 분리되는 구조

request.getRequestDispatcher("/07/registForm.jsp").forward(request, response);

 

---

2) include(내포) :A와 B가 응답에 대한 책임을 나눠갖는 구조,
 하나의 페이지가 여러 view layer에 의해 형성되는 모듈화 구조(페이지 모듈화).

request.getRequestDispatcher("/07/registForm.jsp").include(request, response);

include

 

=> 모듈화 한것이고 

=>클라이언트는 a의존재밖에 모름

response.sendRedirect("/07/registForm.jsp");

왜 에러? 이주소를 사용하는것은 클라이언트임 

컨텍스트 패스가 없어 !!!

 

HTTP 의 기본특성 : Connectful(연결지향형, 하나의 연결만사용하여 재사용),
   Connectless(연결지향X,매번요청이 넘어갈때 응답이 나오면 끊어버리고 새로, 비연결특성), Stateless(무상태 특성)

---

2. Redirect

		1) A 방향으로 요청 발생
		2) A에서 클라이언트로 1) 요청에 대한 응답 전송(302 코드, location 헤더, Body가 없음.)
		   => 목적 옮겨갔다는것을 클라이언트에게 알려주기 위해
		   	  연결 끊긴다.... 
		3) location 헤더의 값인 B로 새로운 요청이 발생. (A존재 와1번모름)
		4) body(message)를 포함한 최종 응답 전송.

 

response.sendRedirect(request.getContextPath()+"/07/registForm.jsp");

=>B의 주소와 같음 (내의견 : 연결만 끊겼다가 요청주소는 바뀌지 않았다.??)

location과 다음번 요청의 request line에 들어가있는 주소는 동일하다.

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>08/flowControl.jsp</title>
</head>
<body>
<h4>웹 어플리케이션에서 페이지 이동</h4>
<pre>
	1. Request Dispatch (요청 분기)
		1) forward :Model2 구조에서 활용. request 처리자(Controller)와 response처리자(View)가 분리되는 구조
		2) include(내포) :A와 B가 응답에 대한 책임을 나눠갖는 구조,
		 하나의 페이지가 여러 view layer에 의해 형성되는 모듈화 구조(페이지 모듈화).
	<%
//		request.getRequestDispatcher("/07/registForm.jsp").forward(request, response);
//		request.getRequestDispatcher("/07/registForm.jsp").include(request, response);
	%>	 
	HTTP 의 기본특성 : Connectful(연결지향형, 하나의 연결만사용하여 재사용),
				   Connectless(연결지향X,매번요청이 넘어갈때 응답이 나오면 끊어버리고 새로, 비연결특성), Stateless(무상태 특성)
	2. Redirect
		1) A 방향으로 요청 발생
		2) A에서 클라이언트로 1) 요청에 대한 응답 전송(302 코드, location 헤더, Body가 없음.)
		   => 목적 옮겨갔다는것을 클라이언트에게 알려주기 위해
		   	  연결 끊긴다.... 
		3) location 헤더의 값인 B로 새로운 요청이 발생. (A존재 와1번모름)
		4) body(message)를 포함한 최종 응답 전송.
	<%
		response.sendRedirect(request.getContextPath()+"/07/registForm.jsp");
	%>
</pre>
</body>
</html>