Nice programing

이름이 같은 여러 쿠키를 처리하는 방법은 무엇입니까?

nicepro 2020. 10. 5. 20:52
반응형

이름이 같은 여러 쿠키를 처리하는 방법은 무엇입니까?


예를 들어 "a"라는 쿠키로 설정하기 위해 다음 HTTP 헤더를 보내는 응용 프로그램이 있다고 가정 해 보겠습니다.

Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1

/example서버에 액세스 하면 두 경로가 모두 유효하므로 "a"라는 두 개의 쿠키가 있습니다! 브라우저는 경로 정보를 보내지 않기 때문에 두 쿠키를 구별 할 수 없습니다.

Cookie: a=2; a=1

이 사건을 어떻게 처리해야합니까? 첫 번째를 선택 하시겠습니까? 모든 쿠키 값으로 목록을 만드시겠습니까? 아니면 그러한 경우가 개발자의 실수로 간주되어야합니까?


에서 SitePoint에이 문서 :

동일한 이름의 여러 쿠키가 주어진 요청 URI와 일치하는 경우 브라우저에서 하나를 선택합니다.

경로가 구체적 일수록 우선 순위가 높아집니다. 그러나 도메인을 포함한 다른 속성에 기반한 우선 순위는 지정되지 않았으며 브라우저마다 다를 수 있습니다. 즉, ".example.org"및 "www.example.org"에 대해 동일한 이름의 쿠키를 설정 한 경우 어떤 쿠키가 다시 전송 될지 확신 할 수 없습니다.

편집 : 2010 년 의이 정보는 오래된 것으로 보입니다. 이제 브라우저가 여러 쿠키를 보낼 수 있습니다. 자세한 내용은 아래 @Nate의 답변을 참조하십시오.


SitePoint의 기사를 참조하는 답변은 완전히 완전하지 않습니다. RFC 6265를 참조하십시오 (공정하게 말하면 이 RFC는이 질문이 게시 된 후 2011 년에 릴리스되었으며, 이는 2000의 이전 RFC 29651997의 RFC 2109 를 대체합니다 ).

섹션 5.4 , 하위 섹션 2는 다음과 같이 말합니다.

사용자 에이전트는 다음 순서로 쿠키 목록을 정렬해야합니다.

  • 경로가 더 긴 쿠키는 경로가 더 짧은 쿠키보다 먼저 나열됩니다.

참고 : 모든 사용자 에이전트가 쿠키 목록을이 순서로 정렬하는 것은 아니지만이 순서는이 문서가 작성되었을 때의 일반적인 관행을 반영하며, 역사적으로이 순서에 (잘못) 의존 한 서버가있었습니다.

섹션 4.2.2에도이 작은 보석이 있습니다 .

... 서버는 직렬화 순서에 의존해서는 안됩니다. 특히, 쿠키 헤더에 동일한 이름을 가진 두 개의 쿠키가 포함되어있는 경우 (예 : 다른 경로 또는 도메인 속성으로 설정된) 서버는 이러한 쿠키가 헤더에 나타나는 순서에 의존해서는 안됩니다.

귀하의 예를 요청 쿠키 ( 쿠키 : A = 2; A = 1 )의 경로와 쿠키 집합주의 / 예 ( A = 2 )의 경로와 하나보다 긴 경로가 / ( A = 1 )과 너무 사양의 권장 사항과 일치하는 첫 번째 줄에 다시 전송됩니다. 따라서 첫 번째 값을 선택할 있다는 가정이 어느 정도 정확 합니다.

불행하게도 RFC에 사용되는 언어는 매우 다릅니다 - 단어의 사용은 안된다SHOULD이 NOT RFC에 모호성을 소개합니다. 이러한 규칙 표시 해야 따라야하지만,하지 않는 요구 사양에 준수 수 있습니다. 이에 대한 RFC를 잘 이해하고 있지만 실제 고객이 무엇을하는지 조사한 것은 아닙니다. HTTP 클라이언트 역할을하는 하나 이상의 브라우저 또는 기타 소프트웨어 Cookie : 헤더 에서 가장 긴 경로 쿠키 (예 : / example )를 먼저 보내지 않을 수 있습니다 .

쿠키의 값을 제어 할 수있는 위치에 있고 솔루션을 완벽하게 만들고 싶다면 다음 중 하나를 선택하는 것이 가장 좋습니다.

  1. 다른 쿠키 이름을 사용하여 다음과 같은 특정 경로에서 재정의합니다.

    • 쿠키 설정 : a-global = 1; Path = /; Version = 1
    • 쿠키 설정 : a-example = 2; Path = / example; Version = 1
  2. 쿠키 값 자체에 필요한 경로 저장 :

    • 쿠키 설정 : a = 1 & path = /; Path = /; Version = 1
    • 쿠키 설정 : a = 2 & path = / example; Path = / example; Version = 1

이 두 가지 해결 방법 모두 사용 가능한 쿠키 목록과 요청 된 URL을 비교하여 원하는 쿠키 값을 선택하기 위해 서버에 추가 논리가 필요합니다. 너무 예쁘지 않습니다. 안타깝게도 RFC는 더 긴 경로가 더 짧은 경로의 쿠키를 완전히 재정의하도록 요구할 수있는 예지력이 없었습니다 (예 : 귀하의 예에서는 Cookie : a = 2 only ).


여러 세션 ID를 사용하여 광범위하게이 작업을 수행하고 일관되게 작동하는 것처럼 보이는 애플리케이션을 확실히 알고 있습니다. 그러나 쿠키가 설정된시기 / 설정된 경로 또는 앱이 각각을 일치 시키려고하는지 여부에 따라 브라우저가 쿠키를 일관된 순서로 반환하기 때문에 알 수 없으며 알아낼 의도가 없습니다. 하나를 기존 세션에 추가합니다.

이 관행은 피하는 것이 좋습니다.

그러나 브라우저 (및 앱)가이 시나리오를 처리하는 방법을 정말로 알고 싶다면 테스트 장비를 구축하고 사용해보십시오.


같은 이름에 대해 여러 값을 갖는 것은 문제가 없습니다. 원한다면 ... 값에 추가 컨텍스트를 포함 할 수도 있습니다.

그렇지 않은 경우 두 컨텍스트를 모두 원하는 경우 물론 다른 이름이 해결책입니다.

대안은보다 구체적인 경로에서도 동일한 경로 (및 도메인)를 사용하여 동일한 쿠키 이름을 보내는 것입니다. 이러한 설정 쿠키 지침은 해당 쿠키의 값을 덮어 씁니다.

이제 가장 중요한 부분 (작동 방식)을 알고 몇 가지 다른 방법으로 필요한 작업을 수행 할 수 있으므로 질문에 대한 제 대답은 다음과 같습니다. 이것은 개발자 문제입니다.


구분해야하는 경우 서로 다른 키 값을 제공해야합니다.

참고 URL : https://stackoverflow.com/questions/4056306/how-to-handle-multiple-cookies-with-the-same-name

반응형