Django-rest-framework: Escapar (ampersand) en URL de API navegables.

Disculpas por la lenta respuesta.
¿Es solo el renderizado lo que es diferente o el HTML de origen no tiene escape?

Hola Tom, en el HTML se veía así:

<a href="http://localhost:8000/endpoint/?param1=Yes+&+No&param2=something">http://localhost:8000/endpoint/?param1=Yes+%26+No&param2=something</a>

Entendido, gracias. Podría valer la pena intentar escribir un caso de prueba fallido para esto.
Idealmente, eso solo ejercitaría BrowsableAPIRendererer , pero probablemente también estaría bien con una prueba de integración completa.

Seguro, estaría feliz de hacerlo. Mirando a través del conjunto de pruebas ahora ... ¿sería el lugar apropiado en RendererEndToEndTests en test_renderers.py?

Suena bien.

Esto tiene que ver con smart_urlquote Django, que es llamado por urlize_quoted_links de

smart_urlquote llama unquote antes de quote , que es lo que quita el original. Esto se agregó en https://github.com/django/django/commit/b70c371fc1f18ea0c43b503122df3f311afc7105 y se actualizó para Django 1.5+.

Entonces, ¿nos importa que esto no sea _ estrictamente_ lo que verá el cliente, o simplemente cerramos esto?
Semánticamente sigue siendo correcto.

Llevar esto del error a la limpieza, ya que está en el límite.

Orientación de DjangoCon: revisión general de este ticket: ¿cuál esperaría que fuera el comportamiento? ¿Es aceptable tal como está?

Estoy en los sprints de django-con y puedo trabajar en esto. No he contribuido antes, por lo que es posible que necesite una guía inicial. Actualmente estoy leyendo las pautas para contribuyentes para DRF y, después de ejecutar las pruebas localmente, podría fallar a alguien en persona o en el irc.

Entendido: siéntete libre de enviarme un ping en IRC o Twitter si no respondo allí.

Cierre por baja prioridad y falta de progreso.
Feliz de reconsiderar si alguien está motivado para retomar esto.

@tomchristie Entiendo que es un problema menor, pero sigue siendo un error. Si hace clic en el enlace, se dirige a la URL incorrecta. Parece más apropiado etiquetar como de baja prioridad que cerrar un problema válido.

Lo investigaré cuando tenga tiempo.

Lamento haber entendido esto de manera diferente, que la URL no era incorrecta, solo que mostraba el enlace en un estilo sin escape, ¿lo he entendido mal?

Es decir. motivo de la etiqueta cleanup , ¿entendió que se trataba de un problema estético?

Oh ya veo. Si eso es correcto. Básicamente, tanto el href como el valor de visualización se escapan, en lugar de solo el valor de visualización.

¡Gracias por una biblioteca tan genial, por cierto!

Lo siento, una vez más :)

Si eso es correcto.

¿Corregir que es un problema estético o corregir que no entendí bien y es un error? :)

Corrija que es un error. :)

Cierre, ya que esto está arreglado por https://code.djangoproject.com/ticket/22267

No he mirado esto todavía, pero ¿necesitamos agregar algo más dado que duplicamos 'urlize'? Además, ¿en qué versión se resuelve esto? Además, ¡genial! ¡Hurra!

Esto no parece estar solucionado en 1.7.1, ¿entonces 1.7.2 o 1.8? Este es el comportamiento que veo con django 1.7.1:

>>> from django.utils.html import smart_urlquote, escape
>>> escape(smart_urlquote('http://qwerty.com'))
u'http://qwerty.com'
>>> escape(smart_urlquote('http://qwerty.com?blah=Yes+%26+No'))
u'http://qwerty.com?blah=Yes+&+No'

.. y director actual de la rama maestra de django:

>>> from django.utils.html import smart_urlquote, escape
>>> escape(smart_urlquote('http://qwerty.com?blah=Yes+%26+No'))
u'http://qwerty.com?blah=Yes+%26+No'

¿Era urlize_quoted_links originalmente una copia modificada de django.utils.html.urlize ? https://github.com/django/django/blob/master/django/utils/html.py#L255 -L352 es significativamente diferente, pero no puedo decir el motivo de la versión separada. Parece que es necesario volver a copiarlo.

Sí, se copió, porque el original no funcionaría para los enlaces de estilo " http://example.org " que tienen comillas simples o dobles encerrándolos, y no hay una anulación fácil para permitirlo. Si hay mucha diferencia, es probable que se deba al cambio gradual de la versión de django mientras que la nuestra se ha mantenido igual.

Vamos a reabrir esto para asegurarnos de que tenemos un ticket de marcador de posición para asegurarnos de que esto se solucione.

Dejando caer el hito en esto ya que hay elementos 3.0.1 de mayor prioridad.

Me pregunto si es posible extraer el caso de prueba fallido de # 2014

Este comentario https://github.com/tomchristie/django-rest-framework/pull/2014#issuecomment -61525348 implica que ese problema se solucionó en Django ascendente. Cerrando esto, pero se volverá a abrir si alguien confirma que sigue siendo un problema.

Solo quiero confirmar que está funcionando ahora :)

Me encanta esta biblioteca, ya está funcionando muy bien, ¡pero aún así sigue mejorando! 👍