html - rutas - URL relativas y barras posteriores

rutas relativas y absolutas html

Question

He buscado en la web esto antes, y sospecho que la respuesta es "no se puede", pero dado que aún no he encontrado una respuesta que sea así de definitiva, creo que vale la pena preguntar aquí. Lo más cerca que he encontrado tocando el problema es El misterio de la barra al final y la URL relativa (que actualmente está inactiva, pero Google tiene una versión en caché solo de texto ).

Debido al diseño tradicional de las URL con una barra inclinada que se interpreta como un directorio y las que no tienen una barra diagonal que se interpreta como un recurso de archivo, y las URL relativas que funcionan fuera del directorio, entonces si la página actual tiene una ruta de acceso

/lorem/ipsum/dolor

una ruta relativa de

not-dolor

se resolverá como

/lorem/ipsum/not-dolor

que naturalmente tiene sentido, cuando /lorem/ipsum/dolor se ve como un recurso de archivo, dolor , sentado en un directorio, /lorem/ipsum/ ; convenciones típicas e intuitivas. Sin embargo, dado que un número significativo de sitios web ahora son aplicaciones dinámicas sin un mapeo de sistema de archivos para cada URL, esto puede causar dolores de cabeza, porque a veces realmente desea trabajar en relación con la ruta como si, en el diseño actual, hubiera una barra final.

¿Existe alguna forma razonable ("no involucrar el procesamiento / variables / otro del servidor, o JavaScript") de utilizar una ruta relativa basada en la ruta actual, y no el "directorio" de la ruta actual? Para que not-dolor pueda ser relativo a /lorem/ipsum/dolor y producir

/lorem/ipsum/dolor/not-dolor

No hay ninguna solución que yo sepa que implique algo como ./not-dolor , ya que . sigue siendo (/lorem/)ipsum/ . Si no se redirige a una barra al final y se asegura de que todos los recursos tengan URL que correspondan a una naturaleza de directorio-ish y de archivo-ish, o que modifiquen la especificación (!), ¿Hay alguna manera de abordar esto?

Answer 1

No.

El problema no está tanto relacionado con el mapeo de director / archivo (lo que nunca se había esperado como la forma en que se realizarían los mapeos, solo permitido como un mapeo conveniente, que a menudo todavía es conveniente).

Está más relacionado con el simple hecho de que el dolor no es lo mismo que el dolor/ y desea dar un nuevo URI a partir de una referencia relativa al dolor/ cuando se combina con uno que termina en dolor .

Lo que puede ser la solución, es actuar con /lorem/ipsum/dolor/ todo el tiempo. Es decir, nunca hablar de /lorem/ipsum/dolor , solo sobre /lorem/ipsum/dolor/ . Después de todo, dado que la asignación de directorio / archivo es, como usted dice, no la única manera de hacer las cosas, no hay ninguna razón por la cual sus nombres de recursos no siempre terminen en barras.

De hecho, esto puede tener más sentido de todos modos, ya que al usar tales enlaces relativos está implicando que existe algún tipo de relación entre /lorem/ipsum/dolor/not-dolor y /lorem/ipsum/dolor . Ahora, aunque /lorem/ipsum/dolor/not-dolor puede no tener mucha relación con /lorem/ipsum/dolor/ , la implicación de que podría estar allí en el URI (sí, los URI son opacos, pero también cuando deben ser tratados como opacos en algunos niveles, se les permite reflejar las relaciones, y esta es precisamente la razón por la cual las referencias relativas al URI tienen sentido). Podría decirse que /lorem/ipsum/dolor/ refleja más claramente su mapeo general de URI a recursos (si no fuera así, no querría pasar del dolor al no dolor de todos modos).

Ahora, esto se reduce a redirigir a una barra inclinada, que dices que quieres evitar (o mejor aún, nunca llevar a alguien al dolor en primer lugar), pero sus ventajas ahora parecen mejores que la conveniencia de URI relativos más fáciles.