HTTP의 숨겨진 기능

HTTP의 숨겨진 기능

---

언급 할 가치가 있다고 생각하는 HTTP의 숨겨진 기능은 무엇입니까?

숨겨진 기능이란 이미 표준의 일부이지만 널리 알려지지 않았거나 사용되지 않은 기능을 의미합니다.

답변 당 하나의 기능 만주세요.

---

Hyper Text Coffee Pot Control Protocol (HTTP의 확장)의 일부인 418 I 'm a teapot 상태 코드 여야합니다 . 매번 나를 웃게 만든다.

2.3.2 418 나는 주전자입니다

주전자로 커피를 추출하려고하면 오류 코드 "418 I 'm a teapot"이 표시됩니다. 결과 엔티티 본문은 짧고 튼튼 할 수 있습니다.

---

리퍼러의 철자 가 틀렸다는 사실 과 철자 오류를 유지해야한다고 결정했습니다.

---

분명한 대답 : PUT, DELETE, TRACE, OPTIONS, CONNECT 메서드

대부분의 사람들은 양식을 작성할 때 사용하는 GET 및 POST 메소드에 대해 알고 있습니다. 브라우저는 또한 HEAD를 많이 사용합니다. 다른 방법은 잘 알려져 있지 않습니다. 그들은 주로 더 구체적인 응용 프로그램에서 사용됩니다.

---

402 지불 필요를 본 사람이 있습니까?

---

204 내용 없음

204는 표시 할 내용이없는 경우에만 해당한다고 생각했지만 사양 은 사용자 에이전트가 "문서보기를 변경하지 않는"추가 동작이있는 것처럼 보입니다.

HOWTO 에 따르면 : AJAX 용 HTTP 204 (콘텐츠 없음)를 반환하도록 Apache 구성

FWIW, Google은 실제로 비슷한 일을합니다. 사용자가 검색 결과의 링크를 클릭 할 때마다 Google은 클릭을 기록하기 위해 자체적으로 핑을 보냅니다. 핑의 응답 코드는 HTTP 204입니다.

또한 204 No Content 는 네트워크 트래픽의 모든 마지막 바이트를 절약하려는 경우 "웹 버그"또는 "비콘"을위한 좋은 기술이라고 제안합니다.

---

응답 코드410 Gone :

(...) 서버 소유자는 해당 리소스에 대한 원격 링크를 제거하기를 원합니다. (...)

웹 스파이더 (특히 Google)는 410을 반환하기 시작하는 페이지의 색인을 제거합니다 (일반적으로 다음 크롤링시).

---

동적 콘텐츠에서 Last_Modified 또는 ETag 헤더 사용

때로는 생성하는 데 비용이 많이 들거나 비용이 많이들 수 있고 요청마다 변경되지 않는 동적 콘텐츠가 있습니다. 생성 된 응답에 Last_Modified 또는 ETag 헤더를 추가 할 수 있습니다.

값 비싼 동적 코드의 맨 위에서 If_Modified_Since 또는 If_None_Match를 사용하여 이미 콘텐츠 요청자가 아직 최신 상태인지 확인할 수 있습니다. 응답 상태를 "304 Unmodified"로 변경하고 요청을 종료하십시오.

일부 서버 측 기술은 이러한 기능을 공식적으로 제공하지만 낮은 ASP-Classic에서도 위의 작업을 수행 할 수 있습니다.

이것은 클라이언트가 항상 최신 정보를 갖도록 보장한다는 점에서 Cache-Control, Expires 헤더를 설정하는 것과 다릅니다.

---

지정된 바이트 범위와 고유 한 파일 식별자 또는 파일 수정 타임 스탬프와 함께 및 요청 헤더를 사용하여 (대형) HTTP 응답 (예 : 파일 다운로드) 을 재개 하도록 요청할 수 있습니다 . 이는 서버가 바이트 범위 요청, 고유 파일 식별자 및 파일 수정 타임 스탬프를 지원한다는 알림과 함께 초기 응답 에서 및 또는 응답 헤더를 각각 전송 한 경우 가능합니다 .RangeIf-RangeAccept-Ranges: bytesETagLast-Modified

초기 응답은 다음과 같을 수 있습니다 ( ETag일반적으로 파일 이름, 크기 및 마지막 수정 타임 스탬프로 구성됨).

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

예를 들어 1KB (1024 바이트)에서 다운로드가 중단되면 클라이언트는 다음과 같이 다시 시작할 수 있습니다.

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

본문에 적절한 바이트와 함께이 응답을 반환해야합니다.

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

---

ReST tries to push HTTP to its limits as an interface protocol.

It's not a hidden feature, but from looking at well-defined ReST APIs one can get quite a nice grip on how HTTP is meant to work and find wonderful examples of what can be achieved with simple combination of HTTP methods, status codes and headers to and fro.

---

Trailer (in contrast to Header)

---

The protocol allows you to define your own custom-fields. These can be used to carry other information if you don't want to use cookies for it.

---

HTTP 100 (Continue) Status

A client can send a request message with a request body to determine if the origin server is willing to accept the request..

In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.

Could be used to avoid traffic from rogue clients.. and/or where bandwidth is a precious commodity.

However, for full use of this feature there are some criteria for HTTP1.1 Client, Servers and Proxies. See the HTTP/1.1 RFC 2616 for further reading on HTTP Connections.

---

Status codes :

• When URI http://www.domain.invalid/index.php?id=44 is called, if the query (id=44) couldn't return ressource, why not return a status code 404?
• When URI http://www.domain.invalid/index.php?id=foo is called whereas id only accepts integers, why not return a status code 400?
• Why, when you enter the wrong login/password, almost all web application return a message like "Authentication failed" with status code 200 (ok, no problem, you do it well) instade of 401?

Yes, status codes seems to be a kind of secret functionality of HTTP to some web developers... But I wonder if the most occult of all the "features" of this protocol isn't its RFC!

참고URL : https://stackoverflow.com/questions/954894/hidden-features-of-http