쿼리 문자열 앞에 슬래시를 건너 뛰어도됩니까?

쿼리 문자열 앞에 슬래시를 건너 뛰어도됩니까?

---

쿼리 문자열을 추가 할 때 항상 후행 슬래시를 건너 뛰는 것이 안전합니까?

즉, 사용할 수 있습니까

http://example.com?querystring

대신에:

http://example.com/?querystring

? 내가 사용한 모든 웹 호스트가 이것을 지원하지만 모든 서버 환경이이 방법을 지원한다고 가정해도 안전합니까? 표준입니까?

---

아니요. 슬래시를 건너 뛰는 것은 올바르지 않습니다. 그것은 수 있습니다 최신 브라우저를 작동 : 그러나, 그것을 수정하지 않습니다.

RFC1738-URL 및 RFC2396-URI를 참조하십시오 .

RFC1738에 따른 형식 (여기서는 스키마 형식을 제외했습니다) :

// <user> : <password> @ <host> : <port> / <url-path>

그리고 다음 사항에 유의하십시오.

... 호스트 (또는 포트)와 url-path 사이의 "/"는 url-path의 일부가 아닙니다.

이 경우 "?" URL 경로의 일부입니다.

... 사용되는 체계와 해석 방식에 따라 다릅니다.

또한 사양에 따라 "/ url-path" 를 생략 하는 것이 완벽하게 유효합니다 .이 경우 "/"가 명시 적으로 포함되어 있습니다.

따라서 url-path 앞에 "/"가 없기 때문에 "foo.com?bar"는 유효하지 않습니다.

---

현대 사양의 문제로서, 예 , 슬래시 건너 허용된다 무엇에 반대, 허용 대답 여기에 주장.

받아 들여진 답변은 RFC 1738 (20 년 이상 전에 출시됨!)을 정확하게 인용하지만, RFC 2396 (1998 년에 출시됨)에 슬래시가 필요하다고 잘못 주장하고 있으며, 두 사양이 모두 RFC 3986에 의해 폐기되었다는 사실을 무시합니다 . 2005 (수용된 답변이 작성되기 몇 년 전) 및 최근에는 WhatWG URL Standard 에서 슬래시를 생략 할 수 있습니다.

이러한 각 사양을 초기부터 최신까지 차례로 고려해 보겠습니다.

---

RFC 1738 : URL (Uniform Resource Locator) (1994 년 출시)

URL에 경로 나 쿼리 문자열 ( 여기서는 라고 함)이 포함되어 있지 않은 경우 생략 할 수 있음 을 지정 하여 슬래시를 포함하도록 암시 적으로 요구합니다 searchpart. 아래 굵은 글씨는 내 것입니다.

HTTP URL은 다음과 같은 형식을 취합니다.

http://<host>:<port>/<path>?<searchpart>

여기서, <host>과 <port>같이 설명된다 3.1 . : <port>를 생략하면 포트 기본값은 80입니다. 사용자 이름이나 암호는 허용되지 않습니다. <path>HTTP 선택기이며 <searchpart>쿼리 문자열입니다. 는 <path>있는대로, 선택 사항 <searchpart>과 그 앞의 "?". 또는 둘 다없는 경우 "/"도 생략 할 수 있습니다.<path><searchpart>

---

RFC 2396 : URI (Uniform Resource Identifier) ​​: 일반 구문 (1998 년 출시, "업데이트"RFC 1738)

여기서 슬래시를 생략 할 수 있습니다. 이 RFC는 스키마 뒤에 이중 슬래시가없는 이상한 URL 구문을 합법화하지만 이러한 구문을 무시하고 ( opaque_part사양의 BNF 에서 가있는 구문 임) 호스트를 포함하는 URL을 고수하면 한다는는 absoluteURI다음과 같이 정의된다 ...

absoluteURI   = scheme ":" ( hier_part | opaque_part )

하고 있다는 hier_part모습이 맘에 :

hier_part     = ( net_path | abs_path ) [ "?" query ]

하고 있다는 net_path모습이 맘에 :

net_path      = "//" authority [ abs_path ]

여기서 an abs_path은 슬래시로 시작하도록 정의됩니다. (가) 있습니다 abs_path입니다 옵션 형태의 URL이 있다는 것을 의미 - 위의 문법에서 scheme://authority?query완전히 합법적이다.

이 변경의 동기는 부록 G.2에 암시되어 있습니다. RFC 1738 및 RFC 1808의 수정 사항 :

물음표 "?" 테스트 결과 많은 응용 프로그램에서 쿼리 구성 요소를 나머지 URI와 분리하기 위해 예약 된 것으로 간주 되었기 때문에 권한 구성 요소의 사용자 정보에 대해 허용 된 문자 집합에서 문자가 제거되었습니다.

즉, 현실 세계의 코드는 URL의 첫 번째 물음표가 쿼리 문자열의 시작을 표시한다고 가정했기 때문에 사양이 현실에 맞게 실용적으로 업데이트되었습니다.

---

RFC 3986 : URI (Uniform Resource Identifier) ​​: 일반 구문 (2005 년 출시, RFC 2396 "구식")

다시, 슬래시를 생략 할 수 있습니다. 사양은 "경로"권위 (호스트)를 포함하는 모든 URI에 필요하며, 그 경로를해야한다는 말하여이 표현 중 하나 슬래시로 시작 하거나 어떤 문자로 구성 :

3. 구문 구성 요소

일반 URI 구문은 체계, 권한, 경로, 쿼리 및 조각이라고하는 구성 요소의 계층 적 시퀀스로 구성됩니다.

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

경로가 비어있을 수 있지만 (문자 없음) 구성표 및 경로 구성 요소가 필요합니다. 권한이있는 경우 경로는 비어 있거나 슬래시 ( "/") 문자로 시작해야합니다.

완전성을 위해 path-abempty나중에 다음과 같이 정의됩니다.

path-abempty  = *( "/" segment )

이것은 실제로 문자를 포함하지 않는 것을 허용합니다.

---

URL Standard by WhatWG (a living standard under active maintenance, first created in 2012, with the goal of obsoleting RFC 3986)

Again, omitting the slash is acceptable, although this time we have no BNF to look at but instead need to read lots of prose.

Section 4.3 tells us:

An absolute-URL string must be one of the following

• a URL-scheme string that is an ASCII case-insensitive match for a special scheme and not an ASCII case-insensitive match for "file", followed by ":" and a scheme-relative-special-URL string
• a URL-scheme string that is not an ASCII case-insensitive match for a special scheme, followed by ":" and a relative-URL string
• a URL-scheme string that is an ASCII case-insensitive match for "file", followed by ":" and a scheme-relative-file-URL string

any optionally followed by "?" and a URL-query string.

Since HTTP and HTTPS are special schemes, any HTTP or HTTPS URL must satisfy the first of those three options - that is, http: or https: followed by a scheme-relative-special-URL string, which:

must be "//", followed by a valid host string, optionally followed by ":" and a URL-port string, optionally followed by a path-absolute-URL string.

A path-absolute-URL string is defined to start with a slash, but is explicitly optional in the definition of an absolute-URL string above; thus, it is permissible to go straight from the host to the "?" and query string, and so URLs like http://example.com?query are legal.

---

Of course, none of this provides a cast-iron guarantee that every web server or HTTP library will accept such URLs, nor that they will treat them as semantically equivalent to a URL that contains the slash. But as far as spec goes, skipping the slash is completely legal.

---

It is not safe to assume that. Web servers and self-contained web applications typically inspect the URL provided in the request, but there is no guarantee that they will treat /abc equal to /abc/. Web servers and self-contained web applications can do whatever they like with the information gleaned from the URL, and it will not necessarily be what you expect. You will have to find out what the convention is for the particular URL in question.

Note, of course, that most web servers and web application frameworks try hard to accept all sorts of inputs and deal with them appropriately. Therefore, in most cases, the web server or self-contained web application will treat /abc equal to /abc/. But remember, because the server can do whatever it likes with the path, that this is simply a generic observation with potentially numerous exceptions.

---

Adding to the accepted answer with some more information I found after researching this problem:

http://tools.ietf.org/html/rfc2396

The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved

Based on this statement, the question-mark should indicate the end of the authority component, with or without the slash.

http://tools.ietf.org/html/rfc1738 (tags replaced)

The {path} is optional, as is the {searchpart} and its preceding "?". If neither {path} nor {searchpart} is present, the "/" may also be omitted.

However, this statement says that the trailing slash can only be omitted if both the path and searchpart are not preset.

In the real world, I've previously been able to omit a trailing slash before a query value, but recently found a situation were that falls down. If you have a query such as this http://my.domain.com?do=something, and you view an html page in Internet Explorer, the link is fixed by IE. If you then click File, Send, Page by e-mail..., the link is added to the email with an invalid format. The issues vary by the content of the query value but we were able to create invalid URLs.

In summary, it should work, but falls down in edge cases.

참고URL : https://stackoverflow.com/questions/1617058/ok-to-skip-slash-before-query-string