Angular.js: encodeUriSegment en resource codifica params, debe ser opcional

Creé una esencia con los cambios para el secuestro :) https://gist.github.com/3749345

+1 a esto. Proporciona una mayor flexibilidad. En nuestro caso de uso, usamos Spring Data Rest para el backend y los métodos de búsqueda son parámetros de ruta que necesitamos asignar a las acciones, idealmente en el mismo objeto de recurso que para las operaciones CRUD básicas.

+1. Nuestras identificaciones contienen barras (usamos RavenDB) y sería una solución limpia si no estuviera codificada

Hacerlo opcional está bien, pero asegúrese de que esté habilitado de forma predeterminada.

Se desaconseja no codificar URI. No hacerlo puede parecer "limpio" ahora, pero te aseguro que te morderá el trasero en esta vida o en la próxima.

Si leo http://www.ietf.org/rfc/rfc3986.txt correctamente, se nos debería permitir la barra inclinada no codificada para el fragmento.

3.5. Fragmento

El componente de identificador de fragmento de un URI permite indirecta
identificación de un recurso secundario por referencia a un recurso primario
recurso e información de identificación adicional. El identificado
recurso secundario puede ser una porción o subconjunto del primario
recurso, alguna vista sobre las representaciones del recurso primario, o
algún otro recurso definido o descrito por esas representaciones. A
componente identificador de fragmento se indica por la presencia de un
carácter de signo de número ("#") y terminado por el final del URI.

 fragment    = *( pchar / "/" / "?" )

...
Los caracteres barra inclinada ("/") y signo de interrogación ("?") pueden
representar datos dentro del identificador de fragmento. Cuidado con que algunos
Es posible que las implementaciones antiguas y erróneas no manejen estos datos correctamente.
cuando se utiliza como URI base para referencias relativas (Sección
5.1).

Caso de uso: $location.hash('/secondary-resource')

Solo tengo curiosidad, ¿es posible evitar este problema codificando dos veces sus parámetros?

Lo sentimos, entonces lo hace aún peor. ¡Solo para confirmar que probé varias aperturas aunque me pareció inútil!

'/', '%252F' --> %25252F

También,

/ %2f --> %252F
'/', '//' --> %2F%2F

Gracias por el pensamiento. La solicitud sigue en pie.

Me encontré con esto hoy. +1
Puede que no me guste, pero nuestras identificaciones también contienen barras. Esto tiene que ser opcional.

+1

+1

+1

+1

+1

+1

Veo una mención de una base de datos (RavenDB) que hace que la implementación actual sea problemática, pero espero que haya un servidor intermediario que espera componentes codificados y los decodifica con la ID correcta en el backend. ¿Alguien podría proporcionar un caso de uso más concreto sobre dónde la codificación forzada está causando problemas (lo siento, no tengo más contexto en RavenDB)?

Dudamos en permitir esto con el diseño actual de $resource, porque facilitaría que la entrada del usuario afectara la ruta de una solicitud.

Uso $ubicación para un diseño REST/hipermedia y no RavenDB (o $recurso). He tenido que trabajar con una versión parcheada de la biblioteca.

También busco confirmación de que, de hecho, esta propuesta también sigue el RFC ; consulte mi comentario anterior.

También podría estar un poco oxidado en la biblioteca, así que muchas disculpas si me equivoco, también hay dos implementaciones de una en recurso en L332 y otra en Angular en 1071 .

Solo necesito el que está en Angular porque es lo que usa $ubicación ;-) (sí, veo el problema aquí, así que no sugeriría tener implementaciones diferentes). Disculpas si tengo algún análisis incorrecto.

+1
¿Alguien tiene una solución para construir direcciones URL de recursos que contengan barras diagonales?

Según la línea de parche mencionada anteriormente en los archivos, las dos implementaciones también se mencionaron anteriormente . Es un dolor.

¿Hay algún movimiento en esto?
Solo agregue un punto en el que realmente podría usar esa opción yo mismo.

Hola,

Tengo el mismo problema, pero la esencia no hace que funcione para mí. ¿Dónde tengo que colocar este método encodeUirSegment o dónde puedo colocar esta opción? :/

Estaba usando un interceptor HTTP para transformar URL. Estaba funcionando hasta que probé en IE11. Interrupciones angulares en solicitudes XHR a URL que incluyen % en IE11. No estoy seguro acerca de IE10. Se supone que Angular es compatible con IE9+ ( referencia )

Supongo que voy a volver al ngResource modificado.

@connorbode --- amigo, como se mencionó en su problema, escriba un caso de prueba fallido =) Este camino ya DEBERÍA estar cubierto, por lo que hay dos posibilidades, o no está cubierto y debería estarlo, o está haciendo algo para romper esta.

¡Averigüemos cuál es!

+1

+1

+1

Imposible trabajar con CouchDB y documentos de diseño (_design/cafehub/_view/menu_items)

¿Pueden hacer +1 en mi solicitud de extracción en lugar de este problema? Soluciona el problema, pero generalmente se ha ignorado desde su presentación. https://github.com/angular/angular.js/pull/7940

+1
Realmente necesito esto para interactuar con algunos servicios web heredados que no realizan URLdecode

+1

Definitivamente existen circunstancias viables y útiles en las que un usuario deseará deshabilitar la codificación de los parámetros de URL (por ejemplo, cuando desea agregar a una URL base una ruta a un recurso).

+1

+1

+1

+1

@toddb solo para su información, su cita de especificaciones se refiere a la parte del fragmento de una URL, es decir, la parte #foo/bar , donde no se requiere ni es apropiado escapar de una barra inclinada. Pero este error se trata de escapar de una barra en la parte de la ruta principal de la URL. En general, no creo que el RFC se aplique a esto, la forma en que el servicio $resource de Angular maneja la coincidencia de patrones y la construcción de URL realmente no preocupa mucho al RFC.

No escapar de las barras en un parámetro de estilo normal :param tiene el problema de que hace que el patrón no sea invertible. Por ejemplo, si tiene /x/:param y permite generar /x/y/z para {param: 'y/z'} , el /x/y/z resultante no podrá analizarse con el patrón de URL.

En mi humilde opinión, podría tener sentido tener una función en los patrones de URL para aceptar un patrón de estrella que coma barras, por ejemplo, "/:param1/:param2/*pathParam" , donde *pathParam comería barras en la URL. Para * parámetros, entonces tendría sentido aceptar también barras inclinadas sin escapar de ellas.

@mprobst : tiene razón en que estaba registrando un error solo alrededor del fragmento. El código tal como lo uso _también_ afecta al fragmento. No estoy usando el servicio $resource sino $location . Si mi memoria no me falla, hay un par de implementaciones del código uriSegment.

El parche de @connorbode de una lectura rápida abordará el problema. Salud

+1

+1

+1

+1

+1

+1

+1

+1

Puede usar la misma sintaxis como en ui-router lib:
http://angular-ui.github.io/ui-router/site/#/api/ui.router.util.type:UrlMatcher

+1

también sucede en el lugar

:+1:

+1

Actualmente estoy haciendo una decodificación para enviar mi URL original al backend

.factory('decodeUriSegment', () => {
    return (url) => {
      return url.replace(/@/g, '%40')
        .replace(/:/g, '%3A')
        .replace(/\$/g, '%24')
        .replace(/,/g, '%2C')
        .replace(/\+/g, '%20');
    };
  });

+1

+1

app.config(function($resourceProvider) {
    $resourceProvider.defaults.stripTrailingSlashes = false;
});

https://github.com/angular/angular.js/pull/5560

+1

Recibo este error en angularjs $ servicio de recursos
Error: encodeUriSegment no es una función

@ ibrahim89 , asegúrese de usar la misma versión de angular y angular-resource.

@gkalpak , gracias!!

mi error esta solucionado