http - principales - los 17 comandos de busqueda
¿Un símbolo final es legal en una URL? (2)
Creo que hay una regla no escrita que todos los RFC deben ser casi imposibles de entender. No eres la primera persona que no puede analizar la gramática y, en mi humilde opinión, Spray también falló.
No hay nada de malo con un signo comercial. Es un carácter legal en el URI utilizado para separar parámetros. Un ampersand final puede ser inútil, pero no es inválido. El spray debería (nuevamente, solo en mi opinión) simplemente ignorarlo.
Una URL como
http://localhost/path?a=b&c=d
está bien, pero ¿cuál es el estado de la misma URL con un símbolo comercial al final?
http://localhost/path?a=b&c=d&
Por ejemplo, la API de Java Servlet permite que Scala''s Spray no lo haga (es decir, arroja un error).
Intenté encontrar la respuesta en la sintaxis URI , pero no estoy seguro de cómo analizar su gramática.
La especificación de sintaxis URI es para URI genéricos. Permite cualquier cosa en la query . No tengo conocimiento de ninguna especificación que en realidad especifique pares de clave = valor separados por un "y" comercial. Creo que es simplemente una convención. Sé que PHP, por ejemplo, ofrece una opción para usar un separador diferente. Pero ahora, todos usan cosas separadas por "y" cuando quieren pares clave-valor. De vez en cuando todavía se encuentra con cosas que lo usan solo para una cadena simple, por ejemplo, http://example.com/?example . Esto es perfectamente válido.
Sin embargo, la respuesta básica es que & es válido en cualquier parte de la cadena de consulta, incluso al final.
Desmitificando la sintaxis de RFC , o Por qué & es válido en cualquier lugar de la cadena de consulta:
Primero tienes
query = *( pchar / "/" / "?" )
(Por lo tanto, una cadena de consulta está formada por cualquier número de pchar y barras y signos de interrogación literales).
Volviendo tienes
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
Y antes todavía
sub-delims = "!" / "$" / "&" / "''" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Entonces, un literal & está en sub-delims que está en pchar , por lo que es válido en la query