Gidhub BE Developer

HTTP Method :: Idempotent, Options, Head, Trace, Connect

2018-10-27
goodGid

Safe Methods

  • 리소스를 수정하지 않는 메소드들(OPTIONS, GET, HEAD 등)Safe하다고 말한다.

  • 대부분의 경우 Idempotent하면 Safe하다.

  • 물론 예외도 있는데 DELETE는 Idempotent 하지만 리소스를 변경하므로 Safe하지 않다.

  • HEAD 는 Response-Body 없이 Header만 얻기 위해 사용한다.

  • OPTIONS 는 해당 리소스에 대해 가능한 Operation이 무엇인지 응답을 얻기 위해 사용한다.

  • 만약 OPTIONS에 대한 응답이 온다면 response Allow 에 가능한 Operation을 사용해야한다.

  • RFC2616 에는 다음과 같이 나와있다.

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. 
This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 

Responses to this method are not cacheable.

번역


Cacheable Methods

  • 왜 OPTIONS 메소드에 대한 응답은 캐시가 불가능한걸까?

  • Stack Overflow에서 관련된 질문 HTTP OPTIONS - Not Cacheable? 답변을 발췌했다.

The OPTIONS HTTP request returns the available methods which can be performed on a resource. (The objects methods)

I can not say for certain why you can not cache the response, but its most likely a precaution. Caching would have little value for the OPTIONS http method.

A Resource is “any information that can be given a name”, that name is its URI. 
the response from the OPTIONs request is only a list of methods that can be requested on this resource (e.g. “GET PUT POST” maybe the response). 
To actually get at the information stored, you must use the GET method.

History, more than anything; OPTIONS was defined that way to start with. 
The underlying reason is that HTTP caches are defined in terms of representations, which means the way you get something out of the cache is GET. 
This is why OPTIONS, PROPFIND, etc. caching are problematic.

번역

  • 리소스는 주어진 URI에 대한 정보인데 OPTIONS는 정보를 가지고 오는 것이 아니다.

  • OPTIONS는 그 URL에 대해 어떤 연산이 가능한지를 알려준다.

  • HTTP에서 이뤄지는 캐싱정보에 대해 이뤄진다.

  • 그렇기 때문에 GET이나 HEAD 같이 정보를 돌려주는 연산에만 캐싱할 수 있다.


Trace, Connect

  • TRACE는 클라이언트가 방금 보낸 요청을 다시 달라고 서버에게 요청하는 것이다.

  • CONNECT는 HTTP 터널링을 할때 쓰인다.

  • 중간의 프록시 서버를 위해서는 CONNECT로 요청하고
    마지막 프록시에서 end-point로는 GET 또는 CONNECT를 날린다.

  • HTTPS라면 CONNECT를
    HTTP라면 둘 중 아무거나 써도 상관 없다.

CONNECT: This method could allow a client to use the web server as a proxy.

번역


TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. 
This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman 

번역


참고


Similar Posts

Comments