HTTP URL의 경로 부분에있는 인코딩 된 슬래시 ( "% 2F")에 해당하는 슬래시 ( "/")입니다.

HTTP URL의 경로 부분에있는 인코딩 된 슬래시 ( "% 2F")에 해당하는 슬래시 ( "/")입니다.

---

URL의 경로 부분 (쿼리 문자열이 아님)에서 "/"및 "% 2F"를 다르게 처리하는 사이트가 있습니다. RFC 또는 실제 세계에 따라 이것이 나쁜 일입니까?

내가 사용하고있는 웹 프레임 워크 (Ruby on Rails)와 그 아래의 레이어 (Passenger, Apache, 예를 들어 Apache에 대해 "ALLOW_ENCODED_SLASHES"를 활성화해야 함)에 약간의 놀라움이 계속 발생하기 때문에 질문합니다. 이제 인코딩 된 슬래시를 완전히 제거하는쪽으로 기울고 있지만 인코딩 된 슬래시와 관련된 이상한 동작이 보이는 버그 보고서를 제출해야하는지 궁금합니다.

처음에 인코딩 된 슬래시가있는 이유에 관해서는 기본적으로 다음과 같은 경로가 있습니다.

:controller/:foo/:bar

여기서 : foo는 슬래시를 포함 할 수있는 경로와 같습니다. 가장 간단한 방법 foo은 라우팅 메커니즘에서 슬래시를 무시하도록 URL 이스케이프 만하는 것이라고 생각했습니다 . 이제는 의심 스럽습니다. 프레임 워크가 실제로 이것을 지원하지 않는다는 것이 꽤 분명하지만 RFC에 따르면 이런 방식으로 수행하는 것이 잘못입니까?

내가 수집 한 정보는 다음과 같습니다.

RFC 1738 (URL) :

일반적으로 URL은 옥텟이 문자로 표시 될 때와 인코딩 될 때 동일한 해석을 갖습니다. 그러나 예약 된 문자에는 해당되지 않습니다. 특정 체계를 위해 예약 된 문자를 인코딩하면 URL의 의미가 변경 될 수 있습니다.

RFC 2396 (URI) :

이러한 문자는 URI 구성 요소 내에서 사용이 예약 된 용도로 제한되기 때문에 "예약 됨"이라고합니다. URI 구성 요소의 데이터가 예약 된 목적과 충돌하는 경우 충돌 데이터는 URI를 형성하기 전에 이스케이프되어야합니다.

(여기서 이스케이프는 예약 된 문자를 인코딩하는 것 이외의 것을 의미합니까?)

RFC 2616 (HTTP / 1.1) :

"reserved"및 "unsafe"세트 (RFC 2396 [42] 참조)에있는 문자 이외의 문자는 ""% "HEX HEX"인코딩과 동일합니다.

Rails에 대한 이 버그 보고서 도 있는데 , 인코딩 된 슬래시가 다르게 작동 할 것으로 예상하는 것 같습니다.

맞습니다. 다른 리소스를 가리 키기 때문에 다른 결과를 기대합니다.

루트 디렉토리에서 리터럴 파일 'foo / bar'를 찾고 있습니다. 이스케이프되지 않은 버전은 foo 디렉토리에서 파일 표시 줄을 찾고 있습니다.

RFC에서 원시 대 인코딩이 예약되지 않은 문자와 동등하다는 것이 분명하지만 예약 된 문자에 대한 이야기는 무엇입니까?

---

수집 한 데이터에서 uri에 인코딩 된 "/"는 application / cgi 수준에서 다시 "/"로 표시되도록하는 경향이 있습니다.

즉, mod_rewrite예를 들어 아파치를 사용하는 경우 인코딩 된 슬래시가있는 URI에 대해 슬래시를 예상하는 패턴과 일치하지 않습니다. 그러나 요청을 처리하기 위해 적절한 module / cgi / ...가 호출되면 디코딩을 수행하고, 예를 들어 URI의 첫 번째 구성 요소로 슬래시를 포함하는 매개 변수를 검색하는 것은 그에게 달려 있습니다.

응용 프로그램이이 데이터를 사용하여 파일 (파일 이름에 슬래시가 포함됨)을 검색하는 경우 이는 아마도 나쁜 일입니다.

요약하면 "/"또는 "% 2F"의 해석이 다른 수준에서 수행되므로 동작의 차이를 보는 것은 완벽하게 정상입니다.

---

%2Fvs 의 이야기는 /초기 W3C 권장 사항에 따르면 슬래시가 «계층 구조를 의미해야합니다» :

예 2

URI

http://www.w3.org/albert/bertram/marie-claude

과

http://www.w3.org/albert/bertram%2Fmarie-claude

두 번째 경우에서 인코딩 된 슬래시는 계층 적 의미가 없기 때문에 동일하지 않습니다.

---

또한 urlencoded 문자가있는 수많은 URL이있는 사이트가 있습니다. 많은 웹 API (Google 웹 마스터 도구 및 여러 Drupal 모듈 포함)가 urlencoded 문자를 통해 이동하는 것을 발견했습니다. 많은 API는 프로세스의 특정 지점에서 URL을 자동으로 디코딩 한 다음 결과를 URL 또는 HTML로 사용합니다. 이러한 문제 중 하나를 발견하면 일반적으로 해당 API에 대한 결과를 이중 인코딩합니다 (% 2f를 % 252f로 변환). 그러나 이것은 이중 인코딩을 기대하지 않는 다른 API를 손상 시키므로 보편적 인 솔루션이 아닙니다.

개인적으로 URL에서 가능한 한 많은 특수 문자를 제거하고 있습니다.

또한 urldecoding에 의존하지 않는 URL에서 ID 번호를 사용하고 있습니다.

example.com/blog/my-amazing-blog%2fstory/yesterday

된다 :

example.com/blog/12354/my-amazing-blog%2fstory/yesterday

이 경우 내 코드는 기사를 찾는 데 12354 만 사용하고 나머지 URL은 내 시스템에서 무시되지만 여전히 SEO에 사용됩니다. 또한이 번호는 사용되지 않는 URL 구성 요소 앞에 표시되어야합니다. 이렇게하면 % 2f가 잘못 디코딩 되더라도 URL은 계속 작동합니다.

또한 URL 실수가 중복 콘텐츠로 변환되지 않도록 표준 태그를 사용해야합니다.

---

Tomcat을 사용하는 경우 VM 속성에 '-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = true'를 추가합니다.

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

---

:foo자연스러운 형태에 슬래시가 포함 된 경우 어떻게해야합니까 ? 당신은 그것을 원하지 않을 것 입니다 . 추천서가 보존하려는 구별이 아닌가요? 구체적으로 다음 과 같습니다.

유닉스 및 기타 디스크 운영 체제 파일 이름 규칙과의 유사성은 순전히 우연한 것으로 간주해야하며 URI를 파일 이름으로 해석해야한다는 것을 나타내지 않아야합니다.

하나는 백업 프로그램으로 온라인 인터페이스를 구축하고, URL 경로의 일부로 경로를 표현하고 싶다고 경우 즉, 그것은 파일 경로에 슬래시를 인코딩 나을 하지 정말의 계층 구조의 일부 자원-그리고 더 중요한 것은 경로 . /backups/2016-07-28content//home/dan/이중 슬래시에서 파일 시스템의 루트를 잃습니다. 슬래시를 이스케이프하는 것은 내가 읽은대로 구별하는 적절한 방법입니다.

참고 URL : https://stackoverflow.com/questions/1957115/is-a-slash-equivalent-to-an-encoded-slash-2f-in-the-path-portion-of-a