HTTP Request와 response, 실제 HTML파일과 JSP파일에서의 적용

HTTP 프로토콜

HyperText Transfer Protocl 은 www(World Wide Web)으로 접속하는 통신 수단이고 오늘날의 웹에 적용해서 사용되고 있습니다. 정적인 페이지에서 동적인 페이지로 만들기위해 발전되었고 복잡하고 웹 애플리케이션을 지원하기 위하여 만들어진 프로토콜입니다. HTTP는 고객이 Request를 보낸 메시지에 근거한 모델을 사용합니다. 그리고 서버는 Response를 돌려줍니다. 덧붙여 HTTP 필터가 가끔 사용자들에게 돌아가는 경우도 있다. 예를 들어 서버에서 발생한 오류 코드들을 브라우저로 보여줄 때가 있다.

HTTP Request(웹 브라우져로부터)

웹 브라우져는 웹 서버와 접속이 확립되면 다음과 같은 요구를 보낸다. 

다음은 전형적인 HTTP request 구조이다.

리퀘스트 행 헤더 공백 본문(본문은 작성하지 않는 경우도 있다. )

다음은 전형적인 http request의 내용이다.

GET /books/search.asp HTTP/1.1              Accept: image/gif, image/xxbitmap, image/jpeg, image/pjpeg, application/xshockwaveflash, application/vnd.msexcel, application/vnd.mspowerpoint, application/msword, */* Referer: http://wahh-app.com/books/default.asp Accept-Language: en-gb,en-us;q=0.5 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: wahh-app.com Cookie: lang=en; JSESSIONID=0000tI8rk7joMx44S2Uu85nSWc_:vsnlc502 (                            공백행                               )

각각의 구조에 대해서 설명한다. 

리퀘스트 행과 메소드

request의 첫번째 행의 다음과 같이 이루어져 있다. 

GET /books/search.asp HTTP/1.1

메소드 URI http버전

GET 메소드를 이용하여 search.asp라는 문서를 요청하며, 이 때 HTTP1.1버전을 사용한다.

메소드란?

서버에게 사용자의 목적을 알리는 역할을 하는데, HTTP에서는 미리 정의 된 GET, HEAD, POST가 있다. 물론 다른 메소드도 지원하지만 현재 서버에서 폭넓게 지원하지는 않는다. 참고로 메소드는 대소문자를 구분한다. 그 예로는 다음과 같다.

GET 

URI의 내용을 취득하는 메소드로써, 웹 브라우저가 문서를 받아 보는데 사용되는 일반적인 방법이다. 사용자가 GET 메소드를 사용하여 요청할 때, 서버는 상태 표시줄, 헤더, 요청된 데이터로 응답한다. 서버에서 오류가 발생하거나 권한이 아닌 상태로 인해 요청을 진행시킬수 없다면 서버는 적절한 오류 메세지를 보낸다. 

HEAD

URI의 내용 중에 헤더 부분을 취득하는 메소드이다. 클라이언트는 다음과 같은 정보를 원한다.

 - 캐시 관련 질의에 유용한 문서의 수정 시간

 - 도착 시간을 측정하거나 문서의 더 작은 버전을 요청을 결정하는 페이지

 레이아웃에 유용한 문서의 크기

 - 클라이언트가 특정 문서만 검색할 수 있도록 해주는 문서의 유형

 - 주문형 서버 질의를 가능하게 하는 서버의 유형

서버가 제공하는 헤더 정보의 대부분은 선택적이며 모든 서버들이 제공하는 것은 아니다. 또한 클라이언트에게 유익한 설계는 요구하는 헤더 정보를 서버가 전달하지 못할 경우, 서버가 융통성 있게 응답하고 기본적인 조치를 취하도록 하는것이다.

POST

URI에 정보를 송신하는 메소드이다. POST 메소드는 다음과 같은 애플리케이션에서 사용될 수 있다. 

- 글을 올릴수 있는 네트워크 서비스

- 명령행에서 실행되는 프로그램

- 서버에 있는 문서의 주석

- 데이터베이스 조작

기타 메소드들에는 LINK, UNLINK, PUT, DELETE, OPTIONS, TRACE, CONNECT 등이 있다.

헤더 부분

통신의 부가정보(메타정보)가 포함되어 있다. 복수의 헤더를 붙이는 것도 가능하다.

호스트명

어떤 이름의 호스트에 액세스 할 것인지를 지정한다. HTTP1.1에서 필수로 바뀌었다. 

User-Agent

웹 서버에 액세스 하고 있는 웹 브라우저의 명칭이 표시된다. 

공백 부분 

헤더의 끝을 알리기 위해 공백 행을 추가한다.

HTTP Response(HTTP 응답)

웹 서버는 웹 브라우저로부터 요구를 받은 뒤, 다음과 같은 응답을 돌려준다.

다음은 전형적인 응답의 구조이다.

STATUS(상태) 행 헤더 공백 본문

다음은 전형적인 응답의 내용이다.

HTTP/1.1 200 OK Date: Sat, 19 May 2007 13:49:37 GMT Server: IBM_HTTP_SERVER/1.3.26.2 Apache/1.3.26 (Unix) Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Content-Length: 24246 (                                공백행                                    )

각각의 구조에 대해서 설명한다.

상태 행 

응답 메세지의 첫번째 행은 다음과 같이 이루어져 있다.

HTTP/1.1 200 OK

http버전 상태 코드 설명문

HTTP버전은 서버가 응답하기 위해 사용하는 HTTP의 버전을 나타내며, 상태코드는 사용자가 요청한 서버의 결과를 나타내는 세자리 숫자이다. 설명문은 우리들이 이해할 수 있는 텍스트로 되어있다.

상태코드란?

서버의 결과를 알기 쉽게 숫자로 나타낸 것이다. 그 예로는 다음과 같은 숫자들이 사용되고 있다.

코드 범위	응답의 의미
100 ~ 199 200 ~ 299 300 ~ 399 400 ~ 499 500 ~ 599	정보 클라이언트의 요청이 성공적이다. 다른 동작이 더 필요해 클라이언트의 요청을 리다이렉트 했다. 클라이언트의 요청이 불완전하다. 서버오류

100 ~199 정보 응답

100 Continue

요청된 초기 부분은 접수되었고 클라이언트는 계속해서 요청할 수 있다.

101 Switching Protocols

서버는 Upgrade 헤더 필드에 명시된 프로토콜로 교환하기 위한 클라이언트 요청에 따르고 있다.

200~299 클라이언트 요청의 성공 응답

200-299의 범위에 있는 응답은 클라이언트의 요청이 성공적이었다는 것을 의미한다.

200 OK

클라이언트의요청이성공적이였으며, 서버는요청한데이터를포함하여응답한다.

201 Created

이 상태 코드는 새로운 URI가 만들어질 때마다 사용된다. 결과 코드와 함께 새로운 데이터가 위치한 곳을 지정하기 위해 Location 헤더가 서버에 의해 주어진다.

202 Accepted

요청은 받아들여 졌지만 즉시 실행되지는 않는다. 트랜잭션에 대한 심층 정보가 서버 응답의 엔티티 몸체에서 주어지기도 한다. 주의할 점은 요청이 정당한 것처럼 보였을 수도 있지만 서버가 요청을 실제로 승인하리라는 보장은 없다는 것이다.

203 Non-Authoritative Information

엔티티 헤더에 있는 정보는 원래 서버가 아니라 로컬이나 다른 서버로부터 온다.

204 No Content

이 코드는 응답할 때 주어지는 헤더이다. 그러나 응답된 실제 내용은 없다는 뜻이다. 이런 응답을 받는 이유는 웹 브라우저가 문서를 보기 위해 갱신을 하지 않았기 때문이다. 이미지맵에서 클라이언트가 이미지의 영역 중 사용하지 않거나 공백인 부분을 클릭했을 때를 처리할 때 유용하다.

205 Reset Content

웹 브라우저가 추가적인 입력을 위해 사용된 트랜잭션을 지우는 것이다. CGI 애플리케이션에서 데이터를 입력받을 때 적합하다.

206 Partial Content

서버가 요청된 크기의 부분 데이터를 반환하고 있다. Range 헤더 지정 요청에 응답하는 데 이용된다. 서버는 반드시 Content-Range 헤더와 응답에 포함된 범위를 지정해야 한다.

300~399 리다이렉션

300~399 범위에 있는 응답 코드는 요청이 수행되지 않았다는 것을 나타내며, 클라이언트는 요청을 성공시키기 위해 다른 행위가 필요하다는 것을 나타낸다.

300 Multiple Choices

요청된 URI는 하나 이상의 리소스를 참조한다. 예를 들면, URI는 여러 개의 언어로 변환된 문서를 참조할 수 있다. 서버에 의해 반환된 엔티티 몸체는 올바른 리소스를선택하는 방법에 대한좀 더 특정한 데이터의 목록을 가지고 있을수 있다.

301 Moved Permanently

요청된 URI는 더 이상 사용되지 않으며 요청에서 지정한 연산은 수행되지 않았다. 요청된 문서를 위한 새로운 위치는 Location 헤더에 명시한다. 앞으로 요청될 모든 문서는 새로운 URI를 사용할 것이다.

302 Found

요청된 URI는 일시적으로 새로운 URI를 가진다. Location 헤더는 새로운 장소를 가리킨다. 만일 이것이 GET이나 HEAD 메소드에 대한 응답이라면 클라이언트는 응답을 받자마자 요청을 해결하기 위해 새로운 URI를 사용해야 한다.

303 See Other

요청된 URI는 다른 URI(Location 헤더에 명시한)에서 찾을 수 있으며, 리소스는 GET 메소드로 구할 수 있다.

304 Not Modified

이것은 If-Modified-Since 헤더에 대한 응답 코드로써 지정한 날짜 이래로 수정되지 않았다. 엔티티 몸체는 보내지 않으며, 클라이언트는 자신의 로컬 사본을 사용해야 한다.

305 Use Proxy

요청된 URI는 Location 헤더에 있는 프록시를 통해서만 접근할 수 있다.

307 Temporary Redirect

요청된 URI가 일시적으로 옮겨졌다. Location 헤더가 새로운 장소를 가리킨다. 이 상태 코드를 받는 즉시, 클라이언트는 요청을 해결하기 위해 새로운 URI를 사용해야 하지만, 앞으로 모든 요청들은 이전의 URI를 사용할 것이다.

400~499 클라이언트 요청의 불안전 응답

400~499 범위에 있는 응답 코드는 클라이언트의 요청이 불안전하며, 클라이언트가 요청을 성공시키려면 다른 정보가 필요하다는 것을 나타낸다.

400 Bad Request

이 응답 코드는 클라이언트의 요청에 문법적인 오류가 있는 것을 서버가 알아냈다는 것을 의미한다.

401 Unauthorized

이 결과 코드는 WWW-Authenticate 헤더와 함께 그 요청에 적당한 권한이 부족했다는 것을 나타내기 위해 주어지며, 이 URI를 다시 요구하면 클라이언트는 적당한 권한으로 접속해야 한다.

402 Payment Required

이 코드는 아직 HTTP로 구현되지 않았다. 하지만 언젠가는 서버의 문서를 받아 보기 위해 지불이 필요하다는 것을 나타낸다.

403 Forbidden

이 요청은 서버가 클라이언트를 가리키고 싶어하지 않아(또는 아무 이유 없이) 거부되었다.

404 Not Found

지정한 URI에 문서가 존재하지 않는다.

405 Method Not Allowed

이 코드는 Allow 헤더와 함께 클라이언트가 사용한 메소드가 이 URI에 대해 지원되지 않는다는 의미이다.

406 Not Acceptable

클라이언트가 지정한 URI는 존재하지만 클라이언트가 원하는 형식이 아니다.서버는 Content-Language, Content-Encoding, 그리고 Content-Type 헤더를 제공한다.

407 Proxy Authentication Required

프록시 서버는 요청된 문서를 보여주기 전에 권한을 필요로 한다. Proxy-Authenticate헤더와 함께 사용한다.

408 Request Time-out

이 응답 코드는 클라이언트의 모든 요청이 지정한 시간(일반적으로 서버의 구성할때 명시한다) 동안 처리되지 않았음을 뜻하며, 서버는 네트워크 연결을 끊는다.

409 Conflict

이 코드는 다른 요청이나 서버의 구성과 충돌이 있음을 나타낸다. 충돌에대한 정보는 응답되는 데이터의 일부로 반환된다.

410 Gone

이 코드는 요청된 URI가 더 이상 존재하지 않고, 서버에서 완전히 사라졌음을 나타낸다.

411 Length Required

서버는Content-Length 헤더가 없는 요청을 받아들이지 않는다.

412 Precondition Failed

하나 이상의 If…헤더에 의해 명시된 조건에 의해 요청을 평가하여 false 값을 가지는 경우이다.

  413 Request Entity Too Large

서버는 실제 본문이 너무 커서 요청을 처리할 수 없다.

  414 Request-URI Too Long

서버는 요청된 URI가 너무 커서 요청을 처리할 수 없다.

 415 Unsupported Media Type

서버는 실제 본문이 지원되는 않는 형식이라 처리할 수 없다.

 416 Requested Range Not Satisfiable

서버는 목표에 대해 어떤 유효한 값도 포함하지 않은 Range 헤더를 찾아냈다. 추가로 If-Range 헤더는 없어졌다.

  417 Expectation Failed

Expect 헤더에서 명시된 조건은 만족될 수 없다.

500~599서버 오류

500~599 범위에 있는 응답 코드는 서버가 오류를 만나거나, 클라이언트의 요청을 수행할 수 없음을 나타낸다.

500 Internal Server Error

이 코드는 서버의 일부(예를 들면, CGI 프로그램)가 멈추었거나 설정에서 오류가 났음을 나타낸다.

501 Not Implemented

이 코드는 클라이언트의 요청된 행위가 서버에서 수행할 수 없음을 나타낸다.

502 Bad Gateway

이 코드는 서버(또는 프록시)가 다른 서버(또는 프록시)로부터의 응답이 적절하지 않음을 나타낸다.

503 Service Unavailable

이 코드는 서비스를 일시적으로 제공할 수 없으나, 앞으로 복구된다는 의미이다.만일 서버가 복구될 때를 알기 위해서는 Retry-After 헤더도 함께 제공해야 한다.

504 Gateway Time-out

이 응답은 게이트웨이나 프록시의 시간이 경과했다는 것만 빼고는 408(Request Time-out)과 같다.

505 HTTP Version not supported

서버가 요청에 사용된HTTP 프로토콜 버전을 지원하지 않는다.

헤더 부분

서버로부터의 응답의 본문은 HTML 문장이지만, 본문 앞에 헤더 부분이 붙여진다.

ETag 

Entity Tag의 줄임말으로써, 본문의 내용을 식별하기 위한 ID같은 역할을 하는 문자열이다. 해당 자원이 업데이트 되기 전에는 결코 변하지 않는 값이다.

Last-Modified

본문에 적혀있는 웹 페이지가 마지막으로 경신된 날짜를 표시한다.

Content-Type

본문에 적혀있는 것이 어떤 종류의 문서인가를 표시한다. 

Content-Length

본문의 사이즈를 나타낸다.

Date

응답을 돌려준 날짜를 나타낸다.

Server

서버로써 사용하고 있는 소프트웨어의 이름을 나타낸다. 

웹 브라우저의 동작

HTTP의 요구와 응답은 페어로 이루어져 있다. 즉, 1회 요구를 전송하면 1개의 파일밖에 취득하지 못한다. 그러나 웹 페이지에는 1개의 HTML 파일 뿐 만이 아니라 복수의 영상 파일이 포함되어 있는 경우가 있다. 그리고 프레임을 사용한 웹 페이지에는 복수의 HTML 파일이 포함되어 있다. 웹 브라우저는 처음에 취득한 HTML 파일을 분석해서 만약 <img> 태그를 발견하면 그 영상 파일을 취득하기 위한 요구를 전송한다. 이러한 식으로 리퀘스트를 반복해서 1개의 웹 페이지를 완성한다. 

폼에서의 입력과 POST, GET 메소드

HTML 폼(doGet.html)

서치 엔진이나 게시판의 사이트에서는, 유저의 입력에 반응해서 웹 페이지가 변화한다. 이런 사이트에서는 HTML 폼을 이용해서 유저로부터 입력을 받는다. 폼에서 이름을 입력받고, 그 데이터를 그대로 출력하는 예를 보이겠다. HTML 문서이다.

<!DOCTYPE html > <html> <head> <meta http-equiv="Content-Type" content= "text/html; charset=UTF-8" > <title> do Get Method</title > </head> <body>                  <p> Input the name : </p >                  <form method="post" action="Ex_Request.jsp" >                                  <p> Family name : <input type="text" name="familyName"></ p>                                  <p> Given name : <input type="text" name="givenName"></ p>                                                   <input type="submit" value="Submit">                                  <input type="reset" value="Cancel">                  </form> </body> </html>

위의 코드의 결과 화면은 다음과 같다.

성을 입력하는 곳에 입력된 문자열은 input태그의 name 속성의 값인 familyName 이라는 파라메터에 저장된다. 이름 또한 마찬가지로 givenName 이라는 파라메터에 저장된다. 폼으로부터 입력되는 데이터는 HTTP의 POST 메소드나 GET 메소드를 이용해 그 데이터를 처리하는 프로그램에 전해진다.  

POST 이용

POST 메소드를 이용해 데이터를 송신할 경우에는, HTML의 form 태그에서 method 속성에 post 라는 문자를 이용해 지정한다.

<form method="post" action="request.jsp">   .....   ..... </form>

POST 메소드를 이용하는 경우에는 request 의 구조 중 본문에 문자열이 들어간다. 위의 HTML 문서의 경우에서 만약 성에 kim, 이름에 lee 를 입력했을 경우 본문의 내용은 다음과 같다.

familyName=kim&givenName=lee

이 문자열을 쿼리라고 부른다. 이러한 POST 메소드는, 쿼리를 request의 본문에 넣어서 데이터를 송신한다. 

GET 이용

GET 메소드를 사용해 데이터를 송신할 경우에는, HTML의 form 태그에서 method 속성을 get 이라고 써주기만 하면 된다.

<form method="get" action="request.jsp">   .....   ..... </form>

GET 메소드를 이용하는 경우에는 request 메세지에 POST 와는 달리 본문에는 아무것도 적히지 않고 리퀘스트 행에 파라메타가 포함된다. 

GET /request.jsp?familyName=kim&givenName=lee HTTP/1.1

리퀘스트 행이 위와 같이 변한다. 위의 HTML 과 같은 경우에는 POST, GET 둘 중의 결과는 같다. 

GET과 POST의 구분

 일단, GET과 POST는 쿼리를 송신하는 방법이 다르다. 많은 경우, POST 메소드를 이용하는 것이 좋다. GET 메소드는 송신 가능한 쿼리의 사이즈에 제한이 있기 때문이다. 또한 유저명과 패스워드를 입력하게 하는 경우, GET 메소드는 URI 중에 패스워드를 표시해 버리는 단점이 있기 때문에, POST 메소드를 이용하는 것이 좋다. 게다가 GET 메소드는 입력된 데이터의 개행을 전달할 수 없다. 그러므로 게시판과 같은 목적으로는 사용할 수가 없다. 

 하지만, GET 메소드를 이용하는 것이 좋은 경우도 있다. 예를 들어, 구글이나 상품 데이터베이스 등의 검색 결과를 북마크에 등록하거나, 링크를 걸 것으로 예상되는 경우에는, GET 메소드를 사용해야 한다. GET 메소드는 쿼리가 URI에 포함되므로 나중에 참고하는 것이 가능하다. 하지만 POST 메소드를 본문에 쿼리가 포함되므로, 나중에 참고하는 것이 불가능하다. 

JSP에서의 요구, 응답의 처리

request 변수와 response 변수

JSP에서는, 웹 브라우저 로부터의 요구를 처리하기 위해서 reqeus 라는 변수를 사용한다. 그리고 웹 서버 로부터의 응답을 처리하기 위해서는 reponse 라는 변수를 사용한다.

일단 밑의 코드와 같이 reqeust를 이용해서 리퀘스트 행과 헤더의 내용을 표시할 수 있다. 

<!DOCTYPE html > <html> <head> <title> handle request</title > </head> <body> <% request.setCharacterEncoding("UTF-8" ); %> <ul>                  <li> Method: <%= request.getMethod() %> </ li>                  <li> Request URI: <%= request.getRequestURI() %> </ li>                  <li> Protocol: <%= request.getProtocol() %> </ li>                  <li> Remote Address: <%= request.getRemoteAddr() %> </ li> </ul> </body> </html>

쿼리의 처리(Ex_Request.jsp)

JSP는 GET의 경우에도 POST의 경우에도 request 변수를 사용해서 쿼리중의 파라메터의 값을 취득할 수 있다. 위의 HTML 문서에서 값을 입력한 뒤, 제출 버튼을 누르면 그것을 처리하는 JSP 코드를 살펴보자. 

<!DOCTYPE html > <html> <head> <title> request process</title > </head> <body>                  <% request.setCharacterEncoding("UTF-8" ); %>                                   <p>                                 Family name:                                  <%= request.getParameter("familyName" ) %>                  </p>                  <p>                                 Given name:                                  <%= request.getParameter("givenName" ) %>                  </p> </body> </html>

request.getParameter 의 인수로 HTML 에서 쓰인 파라메터의 이름을 적으면 된다. 위의 코드의 결과는 다음과 같다.