URL 단축 URL 301 리다이렉션 이해

Question

우리는 PHP의 URL 단축키 프로젝트를 작업 중입니다. 우리는 301 HTTP 리디렉션을 사용하고 자연스럽게 링크 방문을 추적합니다. 하지만 이상한 점이 있습니다 :

URL을 짧게하고 브라우저로 살펴본 후 첫 번째 방문 만 추적되고 다른 요청이 Google 서버로 전송되지 않고 직접 도착 URL로 이동 한 것으로 보입니다. (한 번 시도한 후에 이것이 브라우저 캐시라고 생각합니다). 하지만 :

와 비슷한 서비스를 시도 할 때과 다른 치료법이 있습니다. 동일한 브라우저에서 같은 요청을하는 일부은 약간의 방문 추적에서 추적됩니다. (사실 둘 이상이 아니며 이유를 이해할 수 없으며 논리가 표시되지 않습니다) 301 리디렉션을 사용합니다. 브라우저 창 왼쪽 하단에 "가끔은 기다리고 있습니다."라고 쓰고 때로는 실제로는 임의로 쓰지 않습니다.)

여기에 속임수가 있습니까? 이 치료법이 어떻게 다른가요?

Answer 1

HTTP specification을 읽으십시오. 301 응답은 요구 된 자원이 permanantly로 리디렉션되고있는 새로운 URL로 이동 브라우저에 지시, 더 이상 원래의 URL을 사용하지 않아야합니다 :

10.3.2 301 영구적으로

을 이전 요청 자원에 새로운 영구 URI가 할당되었고 이 자원에 대한 이후 참조는 반환되는 URI 중 하나를 사용해야합니다 (SHOULD). 링크 편집 기능이있는 클라이언트는 에 Request-URI에 대한 참조를 가능하면 서버가 반환 한 새로운 참조 중 하나 이상에 자동으로 다시 연결해야합니다. 이 응답은 다른 방법이없는 한 캐시 가능합니다.

새 영구 URI는 응답의 위치 필드로 지정해야합니다. 요청 방법이 HEAD가 아니라면
응답의 엔티티는 새로운 URI (
) 로의 하이퍼 텍스트 주석을 포함해야한다.

301 상태 코드는 GET 또는 HEAD 이외
다른 요청에 대한 응답으로 수신되는 경우는 사용자가 확인되지 않는 한, 사용자 에이전트가 자동으로
요청을 리디렉션해서는 안이 수도
변경 이후 요청이 내려진 조건.

Note: When automatically redirecting a POST request after 
    receiving a 301 status code, some existing HTTP/1.0 user agents 
    will erroneously change it into a GET request. 

당신이 시도하고 무엇을 위해, 대신 302, 303, 또는 307를 사용해보십시오.

10.3.3 302 실측치

요청 된 자원이 일시적으로 다른 URI.
경우에 따라 리디렉션이 변경 될 수 있으므로 클라이언트는 이후 요청에 대해 Request-URI를 계속 사용해야합니다 (SHOULD ). 이 응답
은 Cache-Control 또는 Expires 헤더로 표시된 경우에만 캐시 가능합니다.
필드.

임시 URI는
응답의 위치 필드로 지정해야합니다. 요청 방법이 HEAD가 아니라면
응답의 엔티티는 새로운 URI (
) 로의 하이퍼 텍스트 주석을 포함해야한다.

302 상태 코드는 GET 또는 HEAD 이외
다른 요청에 대한 응답으로 수신되는 경우는 사용자가 확인되지 않는 한, 사용자 에이전트가 자동으로
요청을 리디렉션해서는 안이 수도
변경 이후 요청이 내려진 조건.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed 
    to change the method on the redirected request. However, most 
    existing user agent implementations treat 302 as if it were a 303 
    response, performing a GET on the Location field-value regardless 
    of the original request method. The status codes 303 and 307 have 
    been added for servers that wish to make unambiguously clear which 
    kind of reaction is expected of the client. 

.

10.3.4 (303) 요청에 대한 응답은 다른 URI에서 찾을 수 있으며 해당 리소스의 GET 메소드를 사용하여 검색되어야한다

다른 참조. 이 방법
은 주로 POST 활성화 스크립트의 출력을
으로 사용자 에이전트를 선택한 리소스로 리디렉션 할 수 있도록하기 위해 존재합니다. 새로운 URI는
원래 요청한 리소스에 대한 대체 참조가 아닙니다. 303
응답을 캐시해서는 안되지만 두 번째
(리디렉션 됨) 요청에 대한 응답을 캐시 할 수 있습니다.

다른 URI는
응답의 위치 필드로 지정해야합니다. 요청 방법이 HEAD가 아니라면
응답의 엔티티는 새로운 URI (
) 로의 하이퍼 텍스트 주석을 포함해야한다.

Note: Many pre-HTTP/1.1 user agents do not understand the 303 
    status. When interoperability with such clients is a concern, the 
    302 status code may be used instead, since most user agents react 
    to a 302 response as described here for 303. 

.

10.3.8 307 임시 리디렉션

요청한 리소스가 일시적으로 다른 URI에 있습니다.
경우에 따라 리디렉션을 변경할 수 있으므로, 클라이언트는 이후 요청에 대해 Request-URI를 계속 사용해야합니다 (SHOULD
). 이 응답
은 Cache-Control 또는 Expires 헤더로 표시된 경우에만 캐시 가능합니다.
필드.

임시 URI는
응답의 위치 필드로 지정해야합니다. 요청 방법은 HEAD,
에 새로운 URI (들)을 하이퍼 링크가 표시된 짧은 하이퍼 텍스트 주석을 포함해야
응답의 실체, 많은 이전 HTTP/1.1 사용자 에이전트가
가 307 개 상태를 이해하지 않기 때문에 아닌 이상 . 그러므로, note는
사용자가 원래 요청을 새로운 URI 인
번에 반복하는 데 필요한 정보를 포함해야합니다 (SHOULD).

307 상태 코드는 GET 또는 HEAD 이외
다른 요청에 대한 응답으로 수신되는 경우는 사용자가 확인되지 않는 한, 사용자 에이전트가 자동으로
요청을 리디렉션해서는 안이 수도
변경 이후 요청이 내려진 조건.

Answer 2

그냥 내 의견을 참고로 는 ..

캐시 제어 헤더이의 역할을한다. 컬 또는 파이어 버그 지속 트래킹을 사용하여 확인하면 위치 이전에 캐시 제어 헤더를 볼 수 있습니다. 90 초 후에 사용자가 링크를 클릭하면 다시 접촉하도록 구성됩니다.