online codificar http url encoding

codificar - Es una barra diagonal("/") equivalente a una barra diagonal codificada("% 2F") en la parte de la ruta de una URL HTTP



url encode php (5)

Tengo un sitio que trata "/" y "% 2F" en la porción de ruta (no en la cadena de consulta) de una URL de manera diferente. ¿Es esto algo malo de hacer según RFC o el mundo real?

Lo pregunto porque sigo encontrándome con pequeñas sorpresas con el framework web que estoy usando (Ruby on Rails) y con las capas que están debajo (Passenger, Apache, por ejemplo, tuve que habilitar "ALLOW_ENCODED_SLASHES" para Apache). Ahora me inclino por deshacerme por completo de las barras codificadas, pero me pregunto si debería estar presentando informes de errores donde veo un comportamiento extraño que involucra las barras codificadas.

En cuanto a por qué tengo las barras codificadas en primer lugar, básicamente tengo rutas como esta:

:controller/:foo/:bar

donde: foo es algo así como un camino que puede contener barras. Pensé que lo más sencillo sería escanear URL foo para que el mecanismo de enrutamiento no tenga en cuenta las barras oblicuas. Ahora estoy teniendo dudas, y está bastante claro que los frameworks realmente no lo soportan, pero de acuerdo con el RFC ¿está mal hacerlo de esta manera?

Aquí hay algo de información que he reunido:

RFC 1738 (URL):

Por lo general, una URL tiene la misma interpretación cuando un octeto está representado por un carácter y cuando está codificado. Sin embargo, esto no es cierto para los caracteres reservados: la codificación de un carácter reservado para un esquema particular puede cambiar la semántica de una URL.

RFC 2396 (URI):

Estos caracteres se llaman "reservados", ya que su uso dentro del componente URI está limitado a su propósito reservado. Si los datos de un componente URI entrarían en conflicto con el propósito reservado, entonces los datos en conflicto se deben escapar antes de formar el URI.

(¿escapar aquí significa algo más que codificar el personaje reservado?)

RFC 2616 (HTTP / 1.1):

Los caracteres distintos de los de los conjuntos "reservado" e "inseguro" (ver RFC 2396 [42]) son equivalentes a su codificación "%" HEX HEX ".

También existe este informe de error para Rails, donde parecen esperar que la barra diagonal codificada se comporte de manera diferente:

Correcto, esperaría resultados diferentes porque apuntan a diferentes recursos.

Está buscando el archivo literal ''foo / bar'' en el directorio raíz. La versión no escapada está buscando la barra de archivos dentro del directorio foo.

Está claro de las RFC que la cruda versus codificada es el equivalente para caracteres sin reserva, pero ¿cuál es la historia para los personajes reservados?

¿Qué hacer si :foo en su forma natural contiene barras? No lo querrías. ¿No es esa la distinción que la recomendación intenta preservar? Observa específicamente ,

La similitud con las convenciones de nombre de archivo del sistema operativo UNIX y de otro disco debe tomarse como pura coincidencia, y no debe tomarse para indicar que los URI deben interpretarse como nombres de archivo.

Si uno estuviera construyendo una interfaz en línea para un programa de respaldo y deseara expresar la ruta como parte de la ruta de la URL, tendría sentido codificar las barras en la ruta del archivo, ya que eso no es realmente parte de la jerarquía de la ruta del archivo. recurso - y más importante, la ruta . /backups/2016-07-28content//home/dan/ pierde la raíz del sistema de archivos en la doble barra. Escapar de las barras es la forma adecuada de distinguir, a medida que lo leo.

A partir de los datos que recopiló, tendería a decir que codificados "/" en un uri están destinados a ser vistos como "/" nuevamente a nivel de aplicación / cgi.

Es decir, que si está utilizando apache con mod_rewrite por ejemplo, no coincidirá con el patrón que espera barras contra el URI con barras recortadas en él. Sin embargo, una vez que se llama al módulo / cgi / ... apropiado para manejar la solicitud, depende de ello realizar la decodificación y, por ejemplo, recuperar un parámetro que incluya barras inclinadas como el primer componente del URI.

Si su aplicación está utilizando estos datos para recuperar un archivo (cuyo nombre de archivo contiene una barra inclinada), eso probablemente sea algo malo.

En resumen, me parece perfectamente normal ver una diferencia de comportamiento en "/" o "% 2F", ya que su interpretación se realizará a diferentes niveles.

También tengo un sitio que tiene numerosas URL con caracteres urlencoded. Estoy descubriendo que muchas API web (incluidas las herramientas de webmaster de Google y varios módulos de Drupal) se cruzan con los caracteres urlencoded. Muchas API decodifican automáticamente urls en algún punto de su proceso y luego usan el resultado como una URL o HTML. Cuando encuentro uno de estos problemas, generalmente codigo doblemente los resultados (que convierte% 2f en% 252f) para esa API. Sin embargo, esto romperá otras API que no esperan doble codificación, por lo que esta no es una solución universal.

Personalmente, me estoy deshaciendo de tantos caracteres especiales en mis URL como sea posible.

Además, estoy usando números de identificación en mis URL que no dependen de urldecoding:

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

se convierte en:

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

en este caso, mi código solo usa 12354 para buscar el artículo, y el resto de la URL es ignorada por mi sistema (pero aún se usa para SEO). Además, este número debe aparecer ANTES de los componentes de URL no utilizados. de esa manera, la url seguirá funcionando, incluso si el% 2f se decodifica incorrectamente.

Además, asegúrese de usar etiquetas canónicas para asegurarse de que los errores de la URL no se traduzcan en contenido duplicado.