Pregunta URL relativas y barras posteriores


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 final y la URL relativa (que actualmente está fuera de servicio, pero Google tiene una versión en caché solo 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 es visto 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 ("que no implique el procesamiento / variables / otro del lado del servidor, o JavaScript") de utilizar una ruta relativa basada en la ruta actual, y no el "directorio" de la ruta actual? Así que eso not-dolor podría ser relativo a /lorem/ipsum/dolor y producir

/lorem/ipsum/dolor/not-dolor

No hay ninguna solución que yo sepa que involucre algo así como ./not-dolor, ya que . es todavía (/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?


32
2018-03-28 10:48


origen


Respuestas:


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 dolor no es lo mismo que dolor/ y desea dar un nuevo URI de una referencia relativa a dolor/ cuando se combina con un final en dolor.

Cuál puede ser la solución, es actuar con /lorem/ipsum/dolor/ todo el tiempo. Es decir, nunca hablando de /lorem/ipsum/dolor en absoluto, 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 hay algún tipo de relación entre /lorem/ipsum/dolor/not-dolor y /lorem/ipsum/dolor. Ahora, mientras /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, si bien deben tratarse como opacos en algunos niveles, son permitido para reflejar las relaciones, y esta es precisamente la razón por la cual las referencias relativas al URI tienen sentido). Podría decirse que por lo tanto, /lorem/ipsum/dolor/refleja más claramente tu mapeo general de URI a recursos (si no fuera así, no querrías pasar de dolor a 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 a dolor en primer lugar), pero sus ventajas ahora parecen mejores que solo la conveniencia de URIs más fáciles.


15
2018-03-28 11:02