* daum.net 접속 시 이미지 파일 다운로드 패킷







서블릿에서 응답 헤더들을 설정하는 방법

 

응답헤더는 클라이언트에게 문서 내용을 한글자라도 보내기 전에 설정해야 한다.

- 일반적으로 setHeader("","") 로 사용한다.

- 서블릿 버전2.1에서는 헤더를 설정하면 바꿀수 없었다 같은 이름으로 헤더를 설정하더라도 이전것은 유지되면서 새로운 해더가 추가되는 형식이 였다. 하지만 서블릿 버전 2.2 에서는 setHeader를 같은 이름으로 하면 덮어쓰기 형식으로 지원하며, 같은 이름으로 추가는 addHeader("","")로 하면 된다.

 

 Accept-Range

 - HTTP1.1 에서 추가

 - 클라이언트가 보낸 Range요청헤더를 받아들 일 수 있는지의 여부를 뜻한다.

- 받아들 일 수 있다면 byte 단위 지정 아니면 none을 지정한다.

 Age

 - HTTP1.1에서 추가

 - 프록시서버에서 사용하는 것으로 원래의서버가 문서를 만든 후 얼마만큼의 시간이 지났는지를 ...

Servlet에선 거의 사용하지 않는다.

 Allow

 - 서버가 지원하는 요청방법(GET,POST등)을 지정한다.

 - 상태코드가 405일 때에는 반드시 이 헤더를 설정해야 한다.

 - 서블릿의 기본 service메소드는 OPTIONS요청에 대해 이 헤더를 자동적으로 만든다.

 Cache-Control

 이것은 문서를 받은 클라이언트가 그 문서를 개시에 어떻게 저장해야 하는것인가를 지시하기 위한 헤더

 

1. public

 - 다른 일반적인 규칙들을 위배하더라도문서를 캐시해도 좋다는 뜻.

2. private

 - 문서를 한 명의 사용자에 대해서만 그리고 비공개(비공유)캐시에만 저장할 수 있다는 뜻.

3. no-cache

 - 문서를 캐시에 저장하지 말라는 뜻.

 - 브라우저는 일반적으로 양식데이터를 포함하는 요청에 대해서는 캐싱하지 않는다.

4. no-store

 - 문서를 캐시뿐만 아니라 다른 어떠한 임시적인 저장장소에도 저장해서는 안된다는 뜻.

 - 보안상 중요한 정보들을 이렇게 처리하자.!

5. must-revalidate

 - 클라이언트는 문서를 사용할 때마다 원래의 서버에 대해 문서의 유효성을 재확인해야 한다.

6. proxy-revalidate

 - 공유 캐시에만 적용된다는 점만 제외한다면 must-revalidate와 동일하다.

7. max-age=xxx 

 - HTTP1.1 을 지원하는 클라이언트데서만 동작.

 - xxx초 이후에는 문서가 유효하지 않을 수 있다는 뜻.

 - 응답에 max-age왕 Expires모두 있다면 max-age가 우선               

8.s-max-age=xxx

 - max-age와 동일하나 공유캐시에 적용되는 것이다.

 Connection

 - 연결방식에 대한 지시를 의미하는 헤더이다.

 - Connection: keep-alive 이면 영속적 연결이 쓰인다.(기본)

   단 Content-Length 응답헤더를 반드시 포함시켜야 한다.

 - 영속적 HTTP연결을 사용하지 않으려면 Connection을 close로 하기보단 Content-Length를 지정하지 않으면 된다.

 - 영속적 연결 자세히 보기

 Content-Encoding

 - 전송 과정 도중에 페이지가 어떻게 인코딩되어야 하는지를 지정한다.

 - 여기서 MIME 정보가 쓰인다.

 Content-Language

 - 문서가 어떤 언어로 쓰여져 있는지를 지정한다.

 Content-Length

 - 응답의 크기(바이트 개수)를 의미한다.

 - 영속적 연결 자세히 보기 에서 ByteArrayOutStream으로 바이트 개수를 알아낸 후 response.setContentLength를 이용해서 헤더에 설정한 후 바이트 스트림으로 writeTo메소드를 호출하는 것이다.

- 바이트 개수를 얻어보자!

 Content-Location

 - HTTP1.1 에서 추가

 - 요청된 문서의 또 다른 주소를 제공하는데 쓰인다.

 Content-MD5

 Content-MD5 응답 헤더는 응답에 포함된 문서의 MD5 다이제스트를 제공한다.

다이제스트(Digest)란? 문서전체가 제대로 전송되었다는걸 확인하기 위한 용도로 쓰인다.

 Content-Range

 - HTTP1.1 에서 추가

 - 문서의 일부분만을 전송할 때 어디서 어디까지의 문서가 전송되는 것인지를 알려주는 역할을 한다. 

 Content-Type

 - 헤더의 응답 문서의 MIME형식을 의미한다.

 Date

 - 현재 일시를 GMT형식으로 지정한 것이다.

 - response.setHeader("Date"."xxx") 로 설정한다

 - 대부분의 서버들은 이 헤더를 자동적으로 설정해 준다.!

 ETag

 - HTTP1.1 에서 추가

 - 클라이언트가 나중에 참조할 때 사용할 이름을 문서에 부여하는 역할을 한다.

 Expires

 - 이 헤더는 문서가 캐시에 남아 있을 수 있는 유효 시간을 설정한다.

 - 10분이상 남아 있지 않도록 하는 예제

 long currentTime = System.currentTimeMillis();

 long termTime = 1000*60*10 // 10분 밀리초 단위로

 response.setDateHeader("Expires",currentTime+termTime);

 - Cache-Control 헤더의 max-age 와 동일한 기능

 Last-Modified

 - 문서가 마지막으로 수정된 일시를 의미한다.

 - getLastModified 를 이용해서 처리하자.!

 Location

 - 문서의 주소를 의미한다.

 - 상태코드가 300번 대이면 반드시 이 헤더를 포함시켜야 한다.

 Pragma

 - HTTP 1.0에서 no-cache로 설정하면, 브라우저는 문서를 캐시에 저장하지 않는다. 그러나 HTTP 1.0 브라우저에 따라서 이 헤더에 대한 반응 방식이 다를 수도 있다는 점을 주의해야 한다.

 - HTTP 1.1 에서는 Cache-Control:no-cache 쪽이 좀 더 신뢰할 수 있다.

 Refresh

 - 브라우저가 지정된 시간 이후에 문서를 자동적으로 다시 로딩하게 만드는데 쓰인다.

 - 반복적인 재요청이 아니다.

 - response.setHeader("Refresh","5;URL=http://host/path");

 - 이 헤더는 HTTP 1.1의 공식 헤더가 아니지만, 넷스케이프와 익스플로러가 모두 지원하고 있어서 거의 공식적인 헤더라고 해도 무방하다. 

 Retry-After

 - 응답 상태 코드 503과 함께 쓰이는 것으로 얼마 후에 문서 요청을 다시 시도해야 하는지 알려주는 역할을 한다.

 Server

 - 웹서버 종류를 알려주는 헤더로 서블릿이 직접 설정하는일은 거의없다.

 Set-Cookie

 - 응답에 담긴 페이지와 연관된 하나의 쿠키를 설정한다.

 - 쿠키가 여러개면 그 개수 만큼의 Set-Cookie들을 설정한다.

 - response.setHeader("Set-Cookie",...) 보다는 response.addCookie를 사용하자!

Trailer

 - HTTP1.1 에서 추가

 - "chunked" 전송 인코딩 방식으로 전송되는 메시지의 꼬리에 존재하는 헤더 필드들을 식별하기 위한 것이다.

 - 별로 사용되진 않는다.

Transfer-Encoding

 - "chunked" 전송 코딩을 사용할 때에는 이 헤더의 값을 chunked로 설정

Upgrade

 - 서버에게 몇 가지 새로운 프로토콜들 중 하나로 전환하자고 요청했을 때 사용한다.

 - 서블릿에서는 이 헤더를 사용하는 일이 거의 없다.

Vary

 - HTTP1.1 에서 추가

 - 클라이언트가 응답 문서의 캐시 여부를 결정할 때 사용할 헤더 이름을 알려주는 역할을 한다.

 - 거의 쓰이진 않는다.

Via

 - HTTP1.1 에서 추가

 - 게이트웨이나 프록시가 사용하는 것으로 요청이 통과한 중간 사이트들의 목록이 담긴다.

Waning

 - 캐시나 내용전송 과정의 오류등을 클라이언트에게 경고하는 역할

 - 거의 쓰이진 않는다.

WWW-Authenticate

 - 상태코드가 401이면 반드시 포함되는 헤더

 

 

@ 참고 및 주의 사항

1.            은 아직도 HTTP1.0 만을 지원하는 브자우저를 고려해서request.getRequestProtocol 로 HTTP1.1을 지원하는지를 체크해야 한다.

2. 공유캐시 : 프록시 서버에 있는 캐시 등을 의미     



출처 - http://blog.naver.com/PostView.nhn?blogId=kazki7074&logNo=120050374533






'Web > HTTP' 카테고리의 다른 글

apache - 파일 크기 제한을 초과함 $HTTPD  (0) 2013.09.09
http - compression  (0) 2013.06.27
http - cache(web cache)  (0) 2013.06.24
http - accept header field  (0) 2013.06.19
http - List of HTTP status codes  (0) 2011.12.16
Posted by linuxism
,


3. New Features and Enhancements in Spring Framework 3.1

This is a list of new features for Spring Framework 3.1. A number of features do not have dedicated reference documentation but do have complete Javadoc. In such cases, fully-qualified class names are given. See also Appendix C, Migrating to Spring Framework 3.1



3.14 "consumes" and "produces" conditions in @RequestMapping

Improved support for specifying media types consumed by a method through the 'Content-Type' header as well as for producible types specified through the 'Accept'header. See the section called “Consumable Media Types” and the section called “Producible Media Types”



Consumable Media Types

You can narrow the primary mapping by specifying a list of consumable media types. The request will be matched only if the Content-Type request header matches the specified media type. For example:

@Controller
@RequestMapping(value = "/pets", method = RequestMethod.POST, consumes="application/json")
public void addPet(@RequestBody Pet pet, Model model) {
    // implementation omitted
}

Consumable media type expressions can also be negated as in !text/plain to match to all requests other than those with Content-Type of text/plain.

[Tip]Tip

The consumes condition is supported on the type and on the method level. Unlike most other conditions, when used at the type level, method-level consumable types override rather than extend type-level consumable types.

Producible Media Types

You can narrow the primary mapping by specifying a list of producible media types. The request will be matched only if the Accept request header matches one of these values. Furthermore, use of the produces condition ensures the actual content type used to generate the response respects the media types specified in the produces condition. For example:

@Controller
@RequestMapping(value = "/pets/{petId}", method = RequestMethod.GET, produces="application/json")
@ResponseBody
public Pet getPet(@PathVariable String petId, Model model) {
    // implementation omitted
}

Just like with consumes, producible media type expressions can be negated as in !text/plain to match to all requests other than those with an Accept header value of text/plain.

[Tip]Tip

The produces condition is supported on the type and on the method level. Unlike most other conditions, when used at the type level, method-level producible types override rather than extend type-level producible types.

출처 - http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/new-in-3.1.html

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping-produces








서버 side 에서 

Producible Media Types은 GET Method로 요청을 받아 서버가 응답(생성)해 줄 때

Consumable Media Types POST Method로 데이터를 받아 서버가 처리(소비)해 줄 때





 












Posted by linuxism
,


part of Hypertext Transfer Protocol -- HTTP/1.1
RFC 2616 Fielding, et al.

14 Header Field Definitions

This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.

14.1 Accept

The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.

       Accept         = "Accept" ":"
                        #( media-range [ accept-params ] )
       media-range    = ( "*/*"
                        | ( type "/" "*" )
                        | ( type "/" subtype )
                        ) *( ";" parameter )
       accept-params  = ";" "q" "=" qvalue *( accept-extension )
       accept-extension = ";" token [ "=" ( token | quoted-string ) ]

The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range MAY include media type parameters that are applicable to that range.

Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1.

      Note: Use of the "q" parameter name to separate media type
      parameters from Accept extension parameters is due to historical
      practice. Although this prevents any media type parameter named
      "q" from being used with a media range, such an event is believed
      to be unlikely given the lack of any "q" parameters in the IANA
      media type registry and the rare usage of any media type
      parameters in Accept. Future media types are discouraged from
      registering any parameter named "q".

The example

       Accept: audio/*; q=0.2, audio/basic

SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."

If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

A more elaborate example is

       Accept: text/plain; q=0.5, text/html,
               text/x-dvi; q=0.8, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

       Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

       1) text/html;level=1
       2) text/html
       3) text/*
       4) */*

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,

       Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
               text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

       text/html;level=1         = 1
       text/html                 = 0.7
       text/plain                = 0.3
       image/jpeg                = 0.5
       text/html;level=2         = 0.4
       text/html;level=3         = 0.7
      Note: A user agent might be provided with a default set of quality
      values for certain media ranges. However, unless the user agent is
      a closed system which cannot interact with other rendering agents,
      this default set ought to be configurable by the user.



출처 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html


'Web > HTTP' 카테고리의 다른 글

apache - 파일 크기 제한을 초과함 $HTTPD  (0) 2013.09.09
http - compression  (0) 2013.06.27
http - cache(web cache)  (0) 2013.06.24
http - request, response header  (0) 2013.06.20
http - List of HTTP status codes  (0) 2011.12.16
Posted by linuxism
,