** request 객체
1. 클라이언트 관련 메소드
2. Parameter 처리
3. Header 처리
** response 객체
1. Header에 값을 저장하기 위한 메소드
2. Data Caching
3. Redirect
** out 객체
** pageContext 객체
** web.xml
1. 설정
2. welcome file
3. 초기화 파라미터 설정
4. 변경 가능성이 있는 고정 문자열 사용
5. 절대 경로와 상대 경로
6. 서버에서의 데이터 저장
7. 서버에서 결과 페이지로 이동
8. 웹 서버에서 요청 처리하는 방식
9. 데이터 조회 작업
10. 데이터 삽입 작업
** 프로그램의 처리 흐름
** request 객체
- 클라이언트의 요청 정보가 저장된 객체이다.
- 자료형은 HttpServletRequest
- jsp 페이지에서는 이미 만들어져 있어서 바로 사용 가능하고 Servlet에서는 요청 처리 메소드의 매개변수로 만들어져 있다.
1. 클라이언트 관련 메소드
1) getRemoteAddr() : 접속한 클라이언트의 IP 주소를 문자열로 리턴해주는 메소드
- 본인 컴퓨터에서 접속하면 127.0.0.1이나 0:0:0:0:0:0:0:1로 리턴
- windows 7 이하에서는 127.0.0.1 주소, 그 이외 운영체제에서는 0:0:0:0:0:0:0:1 주소로 리턴
2) getContextPath() : 서버 도메인이 문자열로 리턴된다.
3) getRequestURI() : 클라이언트의 전체 요청 경로가 문자열로 리턴된다.
https://huembuemhuem.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F
- ContextPath : https://huembuemhuem.tistory.com
- RequestURI : https://huembuemhuem.tistory.com/manage
- 서버에서 클라이언트의 요청을 처리하기 위해서는 RequestURI를 알아야 한다.
- RequestURI를 가지고 직접 작업하기에는 주소가 너무 길다.
- 실제 구현을 할 때는 RequestURI에서 ContextPath를 제외한 부분만을 가지고 처리한다.
- 프레임워크에서는 이 부분이 이미 구현되어 있다.
4) getQueryString() : 파라미터를 가져오는 부분이다.
- URI에서 파라미터는 ? 다음 부분이다.
- Parameter : type=post&returnURL=%2Fmanage%2Fposts%2F
5) getMethod() : 전송 방식을 문자열로 리턴된다.
6) getContentLength() : 클라이언트가 전송한 데이터의 크기를 long으로 리턴된다.
- 클라이언트의 업로드 제한을 가할 때 사용한다.
2. Parameter 처리
1) parameter : Web Client에서 서버에게 넘겨주는 데이터
2) 전송방식
- GET : url의 맨 마지막에 ?를 추가하고 이름=값의 형태로 붙여서 전송하는 방식
- 2개 이상일 때는 &로 구분
- QueryString이라고도 한다.
- URL 뒤에 파라미터를 붙여서 전송하기 때문에 파라미터의 보안이 안되고 길이에 제한이 있지만 바로 해석할 수 있기 때문에 속도는 POST보다 빠르고 자동 재전송 기능이 있다.
- POST로 별도로 지정하기 전에는 기본적으로 GET 방식으로 전송한다.
- POST : header에 파라미터를 숨겨서 전송하는 방식
- 파라미터 길이에 제한이 없고 URL에 붙이지 않기 때문에 파라미터 보안도 가능하지만 자동 재전송 기능이 없다.
- form에서 method를 post로 지정하거나 ajax로 요청을 할 때 method를 post로 지정해야만 이 방식으로 전송이 가능하다.
- 조회를 할 때는 GET 방식으로 이용하지만 그 이외의 경우는 POST 방식을 사용한다.
- 삽입, 삭제, 갱신은 POST 방식으로 하는 것을 권장한다.
- form에 password, textarea, file이 있을 때는 POST 방식으로 처리한다.
- 최근에는 Create - POST, Read - GET, Update - PUT, Delete - DELETE 방식으로 처리하는 것을 권장 : PUT과 DELETE 방식이 적용되지 않는 브라우저가 있기 때문에 아직까지는 GET과 POST만 사용한다.
3) request에서 파라미터 읽기
String getParameter(String name) : name에 해당하는 파라미터 값을 문자열로 리턴하는데 없는 name을 사용하면 null 리턴
String [] getParameterValues(String name) : name에 해당하는 파라미터 값을 문자열 배열로 리턴하는데 없는 name을 사용하면 null 리턴
Enumeration getParameterNames() : 파라미터 이름 전체를 Enumeration(Iterator의 이전 버전)으로 리턴
Map getParameterMap() : 파라미터 이름과 값 전체를 Map으로 묶어서 리턴
- 대다수의 파라미터는 getParameter로 읽지만 checkbox나 select처럼 다중 선택이 가능한 항목은 getParameterValues로 읽어야 한다.
- 파라미터는 입력 형식에 상관없이 항상 문자열
4) 파라미터 만들기
- form 안의 요소는 name 속성을 설정한다.
- ajax에서는 별도의 객체로 생성 - FormData 나 (이름:값, 이름:값,...)
- 링크를 이용할 때는 URL 뒤에 ?를 추가하고 이름=값의 형태로 추가한다.
- 파라미터를 만들 때는 반드시 인코딩을 해야 한다.
5) 파라미터 처리 실습
- inputparameter.html 파일 생성 후 작성
-
- 404 에러가 나면 action에 설정한 파일이 있는지 확인
- 값이 안 보이면 입력을 안 한 것이다.
- null이 나오면 getParameter에 삽입한 name이 잘못된 경우이거나 체크박스나 라이오 버튼에서 선택을 하지 않은 것이다.
6) inputparameter.html 파일의 form에 method="post"를 추가한 후 다시 전송을 하고 URL을 확인
7) parameter 한글 처리
- inputparameter.html 파일의 form의 method를 get과 post로 변경하면 이름 입력란에 한글을 입력하고 전송
- get의 경우 한글이 제대로 나오지만, post의 경우 한글이 깨짐
- get 방식은 WAS가 인코딩을 처리하고 post 방식은 코드가 인코딩을 처리한다.
- get 방식의 경우는 server.xml 파일에 인코딩 처리하는 설정을 추가해야 하는데 tomcat8.0부터는 기본 인코딩이 utf-8이라서 추가적인 처리를 하지 않아도 된다.
- 파라미터를 읽기 전에 request 객체를 가지고 setCharacterEncoding("인코딩 방식")을 호출하면 파라미터 인코딩이 처리된다.
- 파라미터 인코딩 설정 : request.setCharacterEncoding("utf-8");
3. Header 처리
- header는 파라미터와 함께 전송되는 클라이언트의 데이터의 일정인데 URL 창에 보이지 않고 전송된다.
- 헤더에 데이터를 저장해서 전송하는 이유는 URL에 보일 필요가 없는 데이터를 전송하는 것과 크기 문제 때문이다.
- 헤더를 읽는 메소드는 문자열 뿐만 아니라 숫자로 읽어주는 메소드도 존재한다.
- 헤더를 이용해서 날짜를 저장하는 일이 많기 때문에 날짜 연산을 편하게 하기 위해서이다.
- 메소드는 getHeader(String name), getHeaders(String name), getHeaderNames(), getIntHeader(String name), getDateHeader(String name)등의 메소드가 존재한다.
- Enumeration, Iterator, Cursor 등은 여러 개의 데이터를 순차적으로 접근할 수 있도록 해주는 포인터의 개념으로 거의 모든 언어에 존재
** response 객체
- 자료형은 HttpServletResponse
- 응답 객체
- 서버에서 클라이언트에게 응답하기 위한 정보를 저장하는데 이용한다.
1. Header에 값을 저장하기 위한 메소드
addDateHeader(String name, long value)
setDateHeader(String name, long value)
addIntHeader(String name, int value)
setIntHeader(String name, int value)
addHeader(String name, String value)
setHeader(String name, String value)
2. Data Caching
- 출력할 데이터를 브라우저에 저장해서 다음에 요청을 할 때 서버에게 요청하지 않고 브라우저에 저장된 데이터를 출력하는 기능
- 자주 변경되는 데이터가 브라우저에 캐싱되어 있으면 매번 새로운 데이터로 변경하기 위해서 새로고침을 해야 한다.
- 이러한 문제를 해결하기 위해서 브라우저에 캐싱 기능을 중지시키는 방법
reponse.setHeader("Pragma", "no-cache");
reponse.setHeader("Cache-Control", "no-cache");
reponse.addHeader("Cache-Control", "no-store");
reponse.setDateHeader("Expires", 1L);
3. Redirect
- 서버가 특정 요청으로 이동하고자 할 때 사용하는 방식
- URL이 변경되고 request 객체와 response 객체로 새로 만들어 짐
- 기존 요청을 종료하고 새로운 요청이 만들어지는 것이다.
- 조회를 제외한 모든 작업의 마지막은 redirect이다.
- 방법
response.sendRedirect(String url);
** out 객체
- 웹 브라우저에 데이터를 전송하는 역할을 수행하는 출력 스트림이다.
- 서블릿에서는 response 객체의 getWriter()라는 메소드를 호출해서 생성한다.
- 자료형은 JspWriter
- write나 print 메소드를 이용해서 html을 출력하는 것이 가능하다.
- jsp 학습을 할 때는 출력을 편하게 하기 위해 사용하지만 이후에는 자주 사용하지 않는다.
** pageContext 객체
- jsp 페이지 1개와 매핑되는 객체
- 다른 객체들을 가져오는 메소드가 존재
- forwarding : 서버에서 다른 페이지의 결과를 가져오기 위한 방법
- URL이 변경되지 않고 request와 response 객체를 이전 URL로부터 가져오기 때문에 공유가 된다.
- pageContext.forward(String url)
- 도메인 내에서만 가능
** web.xml
- 자바 웹 프로젝트의 환경 설정 파일이다.
- 프로젝트의 WebContent/WEB-INF 디렉토리에 존재해야 한다.
- 프로젝트 안에 이 파일이 없으면 구동이 될 때 서버로부터 이 파일을 복사해서 사용한다.
- 이 파일을 수정하면 서버는 다시 실행해야 변경한 내용이 적용된다.
- 이 파일은 서버가 애플리케이션을 실행할 때 1번만 읽기 때문이다.
1. 설정
- 필터 설정
- 서블릿 설정
- 세션 설정
- 리스너 설정
- welcome file 설정
- error page 설정
- 초기화 파라미터 설정
2. welcome file
- 프로젝트를 실행했을 때 처음 보이는 요청을 설정
- 프로젝트가 실행되면 WAS는 web.xml 파일을 읽어서 welcome-file-list 설정이 있는지 확인하고 이 설정이 있으면 위에서부터 순서대로 요청을 처리하려 하고 요청을 처리하면 처리 페이지를 화면에 출력한다.
3. 초기화 파라미터 설정
<context-param>
<description>설명문</description>
<param-name>파라미터 이름</param-name>
<param-value>파라미터 값</param-value>
</context-param>
- 여러 개 생성 가능
4. 변경 가능성이 있는 고정 문자열 사용
- 소스 코드를 수정하면 컴파일을 다시 해서 클래스를 만들고 빌드를 다시 해야 한다.
- 테스트를 수행할 때 사용하는 데이터 중에 배포를 하면 변경될 가능성이 있는 데이터는 소스 코드에 직접 입력하는 것을 권장하지 않는다.
- 대표적인 데이터는 데이터베이스 경로와 같은 데이터이다.
- 데이터베이스 연동 기능을 테스트할 때는 실제 데이터베이스에 접속하지 않고 대부분 로컬이나 더미 데이터베이스를 가지고 하다가 배포를 할 대 실제 데이터베이스 경로로 변경한다.
- 소스 코드에 데이터베이스 경로를 직접 입력하게 되면 테스트 수행 후 배포를 할 때 데이터베이스 경로를 변경해야 하는데 소스 코드를 수정했기 때문에 컴파일을 다시 하고 빌드를 다시 하게 돼서 예상 못한 오류를 발생시킬 수 있고
- web.xml 파일을 수정한 경우 서버를 다시 실행해야 수정 사항이 적용된다.
7. 절대 경로와 상대 경로
1) 절대 경로 : 루트부터 작성하는 경로로 불변의 경로
- 웹 주소의 경우는 절대 경로 작성이 어렵지 않지만 운영체제의 절대 경로는 운영체제마다 다르기 대문에 작성에 유의해야 한다.
- Windows는 디렉토리 기호가 \이고 나머지 운영체제는 /가 디렉토리 기호이다.
2) 상대 경로 : 현재 위치를 기준으로 하는 경로로 현재 위치가 어디냐에 따라 변경되는 경로
- ../ : 상위 디렉토리
- ./ : 현재 디렉토리
- /는 도메인 경로
- http://localhost:8080/javaweb0616/application.jsp 라면 /는
- http://localhost:8080/javaweb0616인데 html이나 jsp 파일에 /라고 적으면
- http://localhost:8080 이 된다.
- jsp나 서블릿에서 프로젝트 경로를 적을 때 request.getContextPath()를 사용한다.
3) 현재 프로젝트 내의 경로의 절대경로 찾기
- 현재 프로젝트의 root 디렉토리는 WebContent
- WebContent 안에 존재하는 디렉토리의 절대경로
- application.getRealPath("/디렉토리 이름"); //HttpServlet 3.0 부터 사용 가능
- request.getRealPath("/디렉토리 이름"); //HttpServlet 버전에 상관없이 사용 가능
8. 서버에서의 데이터 저장
- 서버에서는 4개의 객체를 이용해서 데이터를 저장한다.
- page, request, session, application
1) 영역의 개념
- page는 현재 페이지 내에서만 유효하고, 다른 페이지로 가면 page는 새로 생성된다.
- request는 하나의 요청에 대해서만 유효하고, forwarding으로 이동한 경우는 request가 공유되지만 그 이외의 방법으로 페이지를 이동하면 request는 다시 생성되기 때문에 공유되지 않는다.
- session은 하나의 윈도우에 대해서만 유효하고, 어떤 방식으로 페이지를 이동해도 데이터를 공유한다.
- 사용자가 웹 브라우저를 실행하고 계속해서 사용해야 하는 데이터가 있으면 session에 저장한다.
- application은 웹 애플리케이션 전체에 1개만 생성되고 모든 사용자가 공유한다.
2) 데이터 관련 메소드
- void setAttribute(String name, Object data) : 데이터 저장
- Object getAttribute(String name) : 데이터를 가져오는 메소드인데 리턴타입은 Object이므로 사용을 할 때는 원래의 자료형으로 형 변환해서 사용한다.
- 없는 이름을 사용하면 null이 리턴된다.
- void removeAttribute(String name) : name에 해당하는 데이터를 삭제
9. 서버에서 결과 페이지로 이동
1) forwarding
- 결과 페이지의 실행 결과를 출력하는 것이다.
- 실제 결과 페이지로 이동하지 않고 결과 페이지의 실행 결과를 가져와서 출력한다.
- 브라우저의 URL이 변경되지 않는다.
- 새로 고침을 하게되면 URL이 다시 호출되기 때문에 이전에 수행했던 작업을 다시 수행한다.
- 삽입이나 삭제 또는 갱신 작업을 했을 대는 forwarding을 이용해서 결과 페이지로 이동하면 안된다.
- 새로고침을 하게되면 이전에 했던 작업을 다시 수행하게 된다.
RequestDispatcher 변수명 = request.getRequestDispatcher(String 포워딩할 페이지);
변수명.forwaed(request객체, response객체);
2) redirect
- 현재 요청의 흐름을 종료하고 새로운 흐름을 만들어서 결과 페이지로 이동하는 방법이다.
- 새로고침을 해도 결과 페이지만 새로 고침한다.
- 삽입, 삭제, 갱신 작업 이후에는 redirect로 이동해야 새로 고침 문제가 발생하지 않는다.
10. 웹 서버에서 요청 처리하는 방식
- 요청 페이지 -> 처리 페이지 및 처리 코드 -> 결과 페이지
- 요청 페이지에서 처리 페이지에게 넘겨주는 데이터를 parameter라고 한다.
- 처리 페이지에서 처리한 후 결과 페이지에 넘겨주는 데이터가 attribute라고 한다.
- 요청 페이지에서 처리 페이지로 요청하는 방법은 a태그 및 form 태그 그리고 javascript를 이용한다.
- 처리 페이지에서 결과 페이지로 이동하는 방법은 forwarding과 redirect 2가지다.
- 처리 페이지 부분이 jsp가 아니고 Servlet이나 Java Class로 변경되면 Model 2 라고 한다.
11. 데이터 조회 작업
- 요청 페이지에서 필요한 파라미터를 가지고 처리 페이지에 요청
- 처리 페이지에서는 파라미터를 읽고 그 읽은 정보를 가지고 데이터베이스에서 조회한 후 결과를 생성해서 request에 저장
- 결과 페이지로 포워딩
- 결과 페이지에서는 request에 저장된 데이터를 읽어서 출력
1) 요청 페이지 - input.jsp
2) 처리 페이지 - process.jsp
3) 결과 페이지 - output.jsp
4) 포워딩
- 포워딩은 결과 페이지의 URL로 변경되지 않는다.
- 결과 페이지에 출력을 해서 그 내용을 가져오는 것이다.
- 새로고침을 하게되면 처리를 다시해서 결과를 재출력하는 것이다.
12. 데이터 삽입 작업
- 입력한 내용을 현재 프로젝트의 insert 디렉토리에 현재 날짜이름.txt 파일에 저장하고 저장 결과를 출력
- insert 디렉토리에 input -> process -> output.jsp 파일 이용
1) 요청 페이지 - input.jsp
2) 처리 페이지 - process.jsp
3) 결과 페이지 - output.jsp
- 여기까지 구현된 페이지
4) 비밀번호 입력란이 있는데 비밀번호가 주소 표시줄이 보이는 문제
- form의 데이터를 POST 방식으로 전송해서 header에 숨겨야 한다.
- form 태그에 method = "post"를 추가
- 여기까지 구현했을 때 한글 깨짐 현상
5) POST 방식으로 전송하면 기본 인코딩이 ISO-8859-1로 설정되서 한글이 깨진다.
- process.jsp에서 파라미터를 읽기 전에 request.setCharacterEncoding("utf-8")을 추가해야 한다.
6) forwarding을 이용해서 결과 출력 페이지로 이동을 하게 되면 URL이 변경되지 않고 결과 페이지의 결과만 가져와서 출력
- 새로고침을 하게되면 처리 부분이 다시 수행된다.
- 삽입, 삭제, 갱신 작업의 경우 결과 페이지로 이동을 할 때 포워딩을 하면 안된다.
- 항상 리다이렉트를 해야 한다.
7) process.jsp 파일의 페이지 이동 부분을 수정
8) redirect를 하게되면 request 객체가 새로 만들어진다.
- redirect를 할 때는 request 객체에 데이터를 저장하면 안되고 session이나 application 객체에 데이터를 저장해야 한다.
- process.jsp의 데이터 저장하는 부분을 수정
- output.jsp의 데이터 불러오는 부분 수정
** 프로그램의 처리 흐름
- 요청(request - input) -> 처리(process) -> 결과 출력(response - output)
- 요청에서 처리하는 쪽으로 넘겨주는 데이터 : parameter
- 처리를 하고 결과를 출력하기 위해서 넘겨주는 데이터 : attribute
- 요청을 하는 방법
- a나 form 태그
- javascript 코드
- 처리를 끝내고 결과를 출력하기 위한 방법
- forwarding
- redirect