Ok para pular Slash antes da sequência de consultas?

StackOverflow https://stackoverflow.com/questions/1617058

  •  06-07-2019
  •  | 
  •  

Pergunta

É seguro sempre pular a barra à direita ao anexar uma string de consulta?

Isto é, posso usar

http://example.com?querystring

ao invés de:

http://example.com/?querystring

? Todos os webhosts que usei suportam isso, mas é seguro assumir que todos os ambientes de servidor apoiarão esse método? É padrão?

Foi útil?

Solução

Não. Não é correto pular a barra. Isto poderia Trabalhe os navegadores modernos: no entanto, isso não o torna correto.

Ver RFC1738 - URL eRFC2396 - URI.

O formato por RFC1738 (eu excluí o formato do esquema aqui):

//u003Cuser> :u003Cpassword> @u003Chost> :u003Cport> /u003Curl-path>

E continua observando que:

... O "/" entre o host (ou porta) e o caminho de URL não faz parte do caminho de URL.

Nesse caso, o "?" faz parte do caminho de URL que

... depende do esquema que está sendo usado, assim como a maneira como é interpretada.

Observe também que, por especificação, é perfeitamente válido para omitir "/URL-path"-Observe que o "/" foi explícito incluído neste caso.

Assim, "foo.com?bar" é inválido porque não há "/" antes do caminho do URL.

Outras dicas

Por uma questão de especificações modernas, sim, é permitido pular a barra, ao contrário do que o resposta aceita Aqui afirma.

Embora a resposta aceita cita corretamente a RFC 1738 (lançada há mais de 20 anos!), Ele afirma erroneamente que a RFC 2396 (lançada em 1998) exige a barra e negligencia que isso Ambas Dessas especificações, por sua vez foram obsoletadas por RFC 3986, lançado em 2005 (ainda vários anos antes da resposta aceita ser escrita) e mais recentemente pelo Whatwg URL padrão, os quais permitem que a barra seja omitida.

Vamos considerar cada uma dessas especificações, por sua vez, do primeiro a mais recente:

RFC 1738: Localizadores de recursos uniformes (URL) (Lançado em 1994)

Requer implicitamente que a barra seja incluída por especificando isso poderia ser omitido E se O URL não contém um caminho nem uma corda de consulta (chamado a searchpart, aqui). Em negrito abaixo é o meu:

Um URL HTTP assume o formulário:

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

Onde <host> e <port> são como descrito em Seção 3.1. Se :<port>é omitido, a porta padrão para 80. Nenhum nome de usuário ou senha é permitida. <path> é um seletor HTTP e <searchpart> é uma string de consulta. o <path> é opcional, como é o <searchpart> e é precedente "?". Se nenhum <path> nem <searchpart> está presente, o "/" também pode ser omitido.

RFC 2396: Identificadores de recursos uniformes (URI): Sintaxe genérica (Lançado em 1998; "Atualizações" RFC 1738)

Aqui é aceitável omitir a barra. Esta RFC legaliza algumas sintaxes de URL estranhas que não têm uma espalhada dupla após o esquema, mas se nós os ignorarmos (eles são os que são os que estão com um opaque_part nas especificações Bnf) e atenha -se a URLs que contêm um host, então descobrimos que um absoluteURI é definido assim ...

absoluteURI   = scheme ":" ( hier_part | opaque_part )

e que um hier_part se parece com isso:

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

e que um net_path se parece com isso:

net_path      = "//" authority [ abs_path ]

onde um abs_path Por sua vez, é definido para começar com uma barra. Observe que o abs_path é opcional na gramática acima - isso significa que um URL da forma scheme://authority?query é completamente legal.

A motivação para essa mudança é sugerida no Apêndice G.2. Modificações da RFC 1738 e RFC 1808:

A marca da pergunta "?" O caractere foi removido do conjunto de caracteres permitidos para o UserInfo no componente da Autoridade, pois os testes mostraram que muitos aplicativos o tratam como reservado para separar o componente de consulta do restante do URI.

Em outras palavras - o código no mundo real estava assumindo que o primeiro ponto de interrogação em um URL, em qualquer lugar, marcou o início de uma sequência de consultas e, portanto, as especificações foram atualizadas pragmaticamente para se alinhar com a realidade.

RFC 3986: Identificador de Recursos Uniformes (URI): Sintaxe genérica (Lançado em 2005; "Obsoletes" RFC 2396)

Novamente, é permitido omitir a barra. As especificações expressam isso dizendo que um "caminho" é necessário em cada URI que contém uma autoridade (host), e esse caminho deve qualquer Comece com uma barra ou consiste em nenhum personagem:

3. Componentes de sintaxe

A sintaxe do URI genérico consiste em uma sequência hierárquica de componentes referidos como esquema, autoridade, caminho, consulta e fragmento.

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

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

Os componentes do esquema e do caminho são necessários, embora o caminho possa estar vazio (sem caracteres). Quando a autoridade está presente, o caminho deve estar vazio ou começar com um caractere de barra ("/").

Para completar, observe que path-abempty é posteriormente definido assim:

path-abempty  = *( "/" segment )

Isso realmente permite que não contenha caracteres.

Padrão de URL Por Whatwg (um padrão vivo sob manutenção ativa, criada pela primeira vez em 2012, com o objetivo de obsoletagem RFC 3986)

Novamente, omitir a barra é aceitável, embora desta vez não tenhamos o BNF para olhar, mas precisamos ler muita prosa.

Seção 4.3 diga-nos:

Um String absoluta-URL deve ser um dos seguintes

Algum opcionalmente seguido por "?" e uma string de url-marery.

Como http e https são esquemas especiais, qualquer URL HTTP ou HTTPS deve satisfazer a primeira dessas três opções - isto é, http: ou https: seguido por a String-URL-URL-Especial Relativa do Esquema, que:

devemos ser "//", seguido por um string de host válida, opcionalmente seguido por ":"E a String de porta URL, opcionalmente seguido por um String de caminho-absoluto-URL.

UMA String de caminho-absoluto-URL é definido para começar com uma barra, mas é explicitamente opcional na definição de uma string absoluta-URL acima; Assim, é permitido ir direto do anfitrião para o "?"E a corda de consulta, e assim os URLs como http://example.com?query são legais.

Obviamente, nada disso fornece uma garantia de ferro fundido de que todos os servidores da Web ou biblioteca HTTP aceitem esses URLs, nem os tratarão como semanticamente equivalentes a um URL que contém a barra. Mas até espec vai, pular a barra é completamente legal.

Isso é não seguro assumir isso. Servidores da Web e aplicativos da Web independentes normalmente inspecionam o URL fornecido na solicitação, mas não há garantia de que eles tratarão /abc igual a /abc/. Servidores da Web e aplicativos da Web independentes podem fazer O que quer que eles gostem Com as informações obtidas no URL, e não será necessariamente o que você espera. Você terá que descobrir o que é a convenção para o URL específico em questão.

Observe, é claro, que a maioria dos servidores da Web e estruturas de aplicativos da Web se esforçam para aceitar todos os tipos de insumos e lidar com eles adequadamente. Portanto, na maioria dos casos, o servidor da Web ou o aplicativo da Web independentes tratarão /abc igual a /abc/. Mas lembre -se, porque o servidor pode fazer o que quiser com o caminho, que isso é simplesmente uma observação genérica com potencialmente numerosas exceções.

Adicionando à resposta aceita com mais informações que encontrei depois de pesquisar esse problema:

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

O componente da autoridade é precedido por uma barra dupla "//" e é encerrado pela próxima barra "/", marca de perguntas "?", Ou até o final do URI. Dentro do componente da autoridade, os personagens ";", ":", "@", "?" E "/" são reservados

Com base nessa afirmação, a questão da pergunta deve indicar o fim do componente da autoridade, com ou sem a barra.

http://tools.ietf.org/html/rfc1738 (Tags substituídas)

O {caminho} é opcional, assim como o {SearchPart} e seu anterior "?". Se nem {caminho} nem {searchPart} estiverem presentes, o "/" também poderá ser omitido.

No entanto, esta declaração diz que a barra de arremesso só pode ser omitida se o caminho e o SearchPart não estiverem predefinidos.

No mundo real, já consegui omitir uma barra à direita antes de um valor de consulta, mas recentemente encontrei uma situação que cai. Se você tem uma consulta como essa http://my.domain.com?do=something, e você vê uma página HTML no Internet Explorer, o link é fixo por ie. Se você clicar em arquivo, enviar, página por e-mail ..., o link será adicionado ao email com um formato inválido. Os problemas variam de acordo com o conteúdo do valor da consulta, mas fomos capazes de criar URLs inválidos.

Em resumo, isso deve trabalho, mas cai em casos de borda.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top