HTTP 요청 (REQUEST)
1) 시작줄의 구성
- HTTP 메소드 : 서버가 수행해야 할 동작
- 요청 타겟 : URL, 프로토콜, 포트, 도메인의 절대 경로
1) Origin : 절대경로. 가장 일반적인 형식.
2) absolute : 완전한 url 형식. 프록시와 연결하는 경우는 get과 함께 사용한다.
3) authority : 도메인 이름 및 옵션 포트. http터널을 구축하는 경우는 connect와 사용한다.
4) asterisk: 서버 전체를 의미한다.
- http 버전 : 응답 메시지에서 써야 할 http 버전
2) 헤더의 구성
- general 헤더 : via같은 헤더는 메시지의 전체에 적용된다.
- request 헤더 : user-agent, accept-type과 같은 헤더는 요청 내용을 구체화시키거나 컨텍스를 제공하고, 조건에 따른 제약사항을 가하기도 하며 요청 내용을 수정한다.
- entity 헤더 : content-type 헤더와 content-length로 구성. 요청 내에 본문이 없는 경우에는 전송되지 않는다.
3) 본문의 구성
-본문은 요청의 마지막에 들어간다. get, head, delete, options처럼 리소스를 가져오는 요청은 보통 본문을 필요로 하지 않아 모든 요청이 본문을 필요로 하는 것은 아니다.
- 단일 리소스 본문 : 헤더 두개로 정의된 단일 파일.
- 다중 리소스 본문 : 멀티파트 본문으로 구성되는 다중 리소스 본문은 파트마다 다른 정보를 지닌다. html폼과 관련이 있다.
HTTP 응답 (RESPONSE)
1) 상태줄(시작 줄)의 구성
- 프로토콜 버전, 상태 코드(요청의 성공 여부), 상태 텍스트(상태 코드에 대한 설명을 글로 나타내어 http 메시지를 이해할 때 도움이 된다.) 로 구성되어있다.
2) 헤더의 구성
- general 헤더 : 요청과 같다.
- response 헤더 : vary와 accept-ranges와 같은 헤더는 상태줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공한다.
- entity 헤더 : 요청과 같다.
3) 본문의 구성
- 응답 마지막 부분에 들어간다. 201, 204 같은 상태 코드를 가진 응답에는 보통 본문이 없다. 즉, 모든 응답에 본문이 들어가지는 않는다.
- 길이가 알려진 단일 리소스 본문 : 헤더 두 개로 정의한다.
- 길이를 모르는 단일 리소스 본문 : Transfer-Encoding 이 chuncked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩되어 있다.
- 다중 리소스 본문 : 서로 다른 정보를 담고 있는 멀티파트로 이루어져 있다. 상대적으로 위 두경우에 비해 보기 힘들다.
HTTP 요청 메소드
- GET : 특정 리소스의 표시를 요청한다. 오직 데이터를 받기만 한다.
- HEAD : GET과 동일한 응답을 요청하나, 응답 본문은 포함하지 않는다.
- POST : 특정 리소스에 엔티티를 제출할 때 쓰인다.
- PUT : 목적 리소스에 모든 현재 표시를 요청 PAYLOA로 바꾼다.
- DELETE : 특정 리소스 삭제를 요청한다.
- CONNECT : 목적 리소스로 식별되는 서버로의 터널을 맺는다.
- OPTIONS : 목적 리소스의 통신을 설정한다.
- TRACE : 목적 리소스의 경로를 따라 메시지 LOOP-BACK 테스트를 ㅎ나다.
- PATCH : 리소스의 부분만을 수정하는 데 쓰인다.
HTTP 응답 상태 코드
100번대 응답 상태 코드 : 정보 교환용으로 사용
200번대 응답 상태 코드 : 데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음을 나타냄
ㄴ EX) 200 OK : 요청이 성공적이다.
300번대 응답 상태 코드 : 자료의 위치가 바뀌었음을 뜻함.
400번대 응답 상태 코드 : 클라이언트측의 오류로 주소 입력 오류, 요청 오류 등을 뜻한다.
ㄴ 400 Bad Request : 잘못된 문법으로 인해 서버가 요청을 이해할 수 없다.
ㄴ 403 Forbidden : 콘텐츠에 접근할 권리가 없다.
ㄴ 404 Not Found : 서버는 요청받은 리소스를 찾을 수 없다.
500번대 응답 상태 코드 : 서버측의 오류로 올바른 요청을 처리할 수 없음을 의미.
get vs post
get : 요청 파라미터들이 url로 인코딩되므로 즐겨찾기가 가능하다. parameters 전송이 가능하지만 url에 넣을 수 있는 파라미터 데이터가 제한된다.
post : 요청 파라미터들이 요청 본문에 포함되고, url에는 나타나지 않는다. 파일 업로드 같은 파라미터 데이터 전송이 가능하다.
1. GET 방식
먼저 method="get" 으로 get html코드를 작성한다.
프로젝트 우클릭 - Run On Server
'Open the server editor and correct the invalid ports' 이부분만 확인하면 된다. 톰캣 포트 넘버가 올바르게 설정되어있지 않아서 나는 오류. 8005 번호를 할당해줬다.
그래도 404오류가 난다면, 오류가 날 때 가장 많이 하는 방법을 사용해본다. 먼저는..
Project -> Clean. 이클립스가 사용하고 있던 정보나 class를 전부 삭제하고 다시 만들어, 이클립스 빌드 중에 꼬인것을 다시 정리하는 개념으로 사용하는 기능이다.
그리고 Maven-Update Project도 해본다.
성공! 참고로 text 속성을 "password" 로 설정하면, 아래와같이 비밀번호를 입력할 때 뜨는 까만 점이 뜬다.
쿼리 전송.
get방식은 url에 내가 전송한 정보들이 나열되어 있다는 것을 알 수 있다.
1. POST 방식
메소드를 post로 수정하고, 정보를 입력해서 전송해본다.
제출을 클릭해도 url상에는 변화가 없다. F12를 눌러 네트워크에서 내가 전송한 정보들을 From Data에서 확인할 수 있다.
이번엔 선택지와 체크박스, 여러 버튼을 추가해본다.
<tr> , <th>, <td> 를 쓰면 표를 만들 수 있다.
css 추가 실습도 해본다. html 본문 내에 style속성을 추가해서 표의 테두리를 만든다.
<head> 태그 내에 <style> 태그를 추가해서 만들 수도 있다. 모든 table에 적용된 것을 볼 수 있다.
이번엔 table 하나에만 class를 주고,
.클래스이름 으로 css 스타일을 적용해본다.
CSS 파일을 별도로 만들어 link rel로 연결할 수도 있다.
MainController.java 창의 기능을 알아보기 위해 login.html을 만든다.
현재는 이런 상태. main.do 라는 요청이 들어오면, main.html을 반환하고, login.do에는 login.html을 반환한다.
index페이지에서 login.do를 포워딩 시키면, 주소창에서 /DU/로 연결할 경우 /login.do를 통해 login.html 이 메인 화면으로 열리게 된다.
▲메인 화면이 login.html로 설정 완료된 상태. 로그인을 누르면 <form action="main.do"> 부분을 통해 main.do가 실행되고, main.html로 연결된다.
로그인을 누르면..
main.html이 나타난다.
'JAVA SPRING' 카테고리의 다른 글
| JSP 스크립트, 액션 태그 (0) | 2021.07.27 |
|---|---|
| 서블릿 확장 API, 쿠키와 세션, 필터와 리스너 (0) | 2021.07.23 |
| 서블릿 - get, post, @WebServlet, 비즈니스 로직 처리(DAO, VO, 커넥션풀) (0) | 2021.07.23 |
| 웹 프로그래밍 - 2일차 (0) | 2021.07.09 |
| 웹프로그래밍 - 1일차 (0) | 2021.07.09 |
