웹 : 응답상태코드 : 0308

🚩오늘 수업

응답데이터가 어떻게 패키징 되는가?

그과정에서 상태코드가 어떻게 

어떤 상태코드가 있느냐

어떻게 써먹을 것인가

---

response의 모든 조건은 request에서 발생한다.

( Peer : 양 끝단 )

답장이 왔을 때 제일 궁금한 것은 ? 나의 요청대로 오는가

성공 => 글자로는 표현이 너무나 다양함. 그래서 성공의 표현을 숫자로 하는것 : status code

성공의 결과를 표현하는 기준 : R.Header, R.Body

클라이언트가 기본적으로 GET메서드로 보내고 그 응답 자원이 가는 곳은 R.Body == ContentBody, message Body라고도 함

header : 응답데이터를 담기 위해 meta data가 또 있다.

==> 전체 사이즈가 얼마인지 body를 꾸며주는 용도로. response.setContentType 으로 사용해왔음

 

forward 와 redirect의 차이 : location을 어떻게 써먹느냐 ==> ...

---

Http resonse packaging

사용파일 : responseDesc.jsp

 

<response Line>

<pre>
1. response Line : 요청 처리 결과를 표현하는 상태코드(status code)
    ex) sendError(sc), setStatus(sc)
    status code
    100~ : ING... webSocket : Http 의 하위 프로토콜 형태로 connectfull 구조를 가짐.
    200~ : OK(success)
    300~ : 클라이언트의 다음 액션에 대한 유도. body 가 없이 line+header 로만 응답이 구성됨.
        ex)
        304 : Not Modified 수정되지않았다. 
        301/302/307 : Moved + Location 헤더와 병용. 
        //옮겨간 새로운 위치 완전히 옮겨감 영구적
            / 임시로이동함, 기존정보 없애고 get방식으로 새로운 요청sendredirect, framework전
            /임시로 이동함, 기존정보 가지고 이동, 후

    400~ : client side failure
        400 : Bad Request, 요청 데이터 검증에 활용.
        404 : Not Found
        405 : Method Not Allowed
        401/403 : Authentication(인증)/Authorization(인가)	기반의 접근제어에 활용. 
        406/415 : 요청이나 응답의 컨텐츠 타입과 관련하여 활용.
                406 : Not Acceptable - accept request header 에 있는 MIME 캔텐츠를 생성할 수 없음.
                415 : UnSuppored Media Type - request body content 를 해석할 수 없음.

    500~ : server side failure , 500(Internal server error)
</pre>

 

 

<%=HttpServletResponse.SC %> 로 확인가능

response 요청은 5개로 분리된다.

100 , 200 , 300 번대는 성공 혹은 애매// 400, 500 실패쪽

300 대 : 300번대는 캐쉬를 가지고 이동해서 한가지 일을 더해라

line과 header는 있고 body가 없다.

300번이 하는 일 : 1. 나는 아니에요 2. 새로운 위치는 이거에요  >> location정보를 숨겨놓는다.

redirect : 나는 아니에요 새로운 주소 이거에요 

302 : 클라이언트한테 300번대 코드와 새로운 요청할 것을 전달. 다음 행동을 유도

304 : 캐시 데이터를 가져가보는데 그거수정된적이 없어 써도돼. 다음 행동

 

400 대는 client side failure, 상태코드를 쪼개서 자세히 노출하여 개선해서 다시 접속할 수 있도록 정보 전달 열심히

404 : 자원이 없다 제공할 수 있는 서비스가 없다.

405 : Method Not Allowed, do collback method를 override하지 않아서. 반드시 수퍼코드 제거하기

401/403 : 적정한 유저가 정당한요구를 하는지 확인해보고 허가하겠다. authentication 허가 // auth 데이터보호조치

406 : json으로 줘! - 못줘!  req.accept / 415 : req.body (contentType)         

500 대는 server side failur, 그런데 대부분 500으로만 노출한다.

 클라이언트가 모두 선한 목적으로 접근하는 것은 아니기에 서버 사이드의 일을 감춰두고 노출하지 않는 것. 보안.

<response Header>

<pre>
2. response Header : response content 에 대한 meta data, Content-*
    ex) setHeader(name, value), setIntHeader(name, intValue), setDateHeader(name, longValue)
        addHeader(name, value)
    1) response body content 에 대한 설정 : Content-*
    2) 캐시 제어를 위한 설정 : Cache-Control
        <a href="cacheControl.jsp">캐시 제어</a>
    3) auto request : Refresh
        <a href="autoRequest.jsp">auto request</a>
    4) flow control : Location
</pre>

응답 헤더를 이용한 캐시 제어 : server기준이아닌 client 기준의 프로토콜 버전을 설정해야한다.

cache 버전 선택 ==> 클라이언트가 어떤 버전을 쓸지 모르니 다 써야한다.

//cache Control

<h4> 응답 헤더를 이용한 캐시 제어 </h4>
<pre>
	Pragma(http 1.0), Cache-Control(http 1.1), Expires(all version)
	
	Pragma(http 1.0), Cache-Control(http 1.1)
		- public - 범용캐쉬. 양쪽 서버에 모두 저장한다. (서버, 프록시서버)
		- private - 
		- no-cache - 캐싱하지 않는다. 저장된 캐시가 있다면 사용전에 만료여부를 항상 확인한다.
		- no-store - 캐싱하지 않는다. 
		- must-validate - 항상 검증해야해. 그러다 304가 온다.
		- max-ages : miliseconds
		<%
			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);
		%>
</pre>

Http 특성

1. stateless : 상태가 없다.

2. Connetless : 비커넥트 지향 방식 : <->db connect (statefull)

 >> Http 사용자는 대상자가 불특정 다수 : 사용하는 패턴이 다르다. : 불필요한 연결도 상태가 유지된다.

 >> 닫으면 연결을 끊어버린다 >> 양측의 정보를 모두 지운다. >> stateless >> 대화가 불가능하다. :"아침먹었어?(x100)"

 >> session과 쿠키가 나옴. 저장할 수 있는 형태가 생김 statefull방식됨

 

>connetless 단점 >> pushmessage = 연결이 있어야 하능. connectless는 불가능

>> webSocket 서브 프로토콜 connectfull방식됨 >> 100번대 상태코드

https://socketsbay.com/test-websockets

WebSockets - 👩‍💻 Do tests for FREE 💪 - SocketsBay.com

<webSocket Test>

//auto request
<h4>현재 서버의 시간 : <span id="timeArea"></span></h4>
<h4>주기적인 자동 요청 발생</h4>
<pre>
1. server side : response header (Refresh) <%-- <% response.setIntHeader("Refresh", 1); %>	--%>
2. client side
	- JS : scheduling function(setTimeout : 지연시간설정, setInterval : 주기설정하고반복)
	- HTML : meta
</pre>
<textarea row="5" cols="100"></textarea>
<script type="text/javascript">
	let timeArea = $('#timeArea');
	setInterval(function(){
		$.ajax({
			url : "<%=request.getContextPath() %>/07/getServerTime.jsp",
			dataType : "html"
		}).done(function(resp, textStatus, jqXHR) {
			timeArea.html(resp);
		}).fail(function(jqXHR, status, error) {
			console.log(`상태코드 : \${status}, 에러메세지 : \${error}`);
		});
	}, 1000);
</script>

--> 1초마다 새로운 요청 생성 : 롱폴링 방식 : 과부화걸리는 단점, 완전한 실시간이 아닌 단점 --> socket 쓰게됨.

Expires(all version) : 만료설정

범용캐쉬 public : 양쪽 서버 모두에 저장(서버, 프록시서버)/ 제한적인 캐쉬 현재개정안에서만 private : 한쪽서버에

프록시서버 : 대체서버 ,클라이언트 대신에 인터넷상의 다른 서버에 접속하는 서버

 

캐시저장소는 클라이언트단에서 가지고 있으며 보호가 필요하다면 no-cache나 no-store사용해야한다.

 

비동기 : 자원의 락 개념이 없어서 무질서하게 사용하는 것. 동기는 락개념이 있어서 락을 받아야 사용가

<response Body>