Django-rest-framework: Escapando (e comercial) em URLs de API navegáveis.

Desculpas pela resposta lenta.
É apenas a renderização que é diferente ou o próprio HTML de origem não tem escape?

Olá Tom, no HTML parecia algo assim:

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

Entendi, obrigado - pode valer a pena tentar escrever um caso de teste com falha para isso.
Idealmente, isso apenas exercitaria BrowsableAPIRendererer , mas provavelmente também estaria bom com um teste de integração completo.

Claro, eu ficaria feliz. Olhando para o conjunto de testes agora ... o local apropriado seria RendererEndToEndTests em test_renderers.py?

Parece bom.

Isso tem a ver com smart_urlquote do urlize_quoted_links do DRF , que é o que lida com a conversão dentro da API navegável. _Acho_ que a diferença entre o texto do link e o próprio link pode ser um escape do Django, mas honestamente não tenho certeza disso.

smart_urlquote chama unquote antes de quote , que é o que retira o original. Isso foi adicionado em https://github.com/django/django/commit/b70c371fc1f18ea0c43b503122df3f311afc7105 e backported para Django 1.5+.

Então, nós nos importamos que isso não seja _estritamente_ o que o cliente verá, ou vamos apenas fechar isso?
Semanticamente, ainda está correto.

Empurrando isso do bug para a limpeza, já que é limítrofe.

Orientação do DjangoCon - revisão geral deste tíquete - como você espera que seja o comportamento, é aceitável no estado em que se encontra?

Estou nas corridas de django-con e posso trabalhar nisso. Eu não contribuí antes, então posso precisar de alguma orientação inicial. No momento, estou lendo as diretrizes do contribuidor para DRF e, depois de executar os testes localmente, posso bugar alguém pessoalmente ou no irc.

Peguei você - sinta-se à vontade para me enviar um ping no IRC ou no Twitter se eu não responder lá.

Fechando por baixa prioridade e falta de progresso.
Fico feliz em reconsiderar se alguém está motivado para retomar o assunto.

@tomchristie Eu entendo que seja um problema menor, mas ainda é um bug. Se você clicar no link, ele irá para o URL errado. Parece mais apropriado marcar como prioridade baixa do que fechar um problema válido.

Vou averiguar quando tiver tempo.

Desculpe, eu entendi isso de forma diferente - que o URL não estava errado, apenas renderizava o link em um estilo sem escape, eu entendi mal?

Ie. razão para a tag cleanup , entendeu que este é um problema cosmético?

Oh, eu vejo. Sim esta correto. Basicamente, href e o valor de exibição estão sendo escapados, em vez de apenas o valor de exibição.

Obrigado por uma ótima biblioteca, aliás!

Desculpe, mais uma vez :)

Sim esta correto.

Corrija que é um problema cosmético ou corrija que entendi mal e que é um bug? :)

Corrija que é um bug. :)

Fechando, pois isso foi corrigido por https://code.djangoproject.com/ticket/22267

Ainda não olhei para isso, mas precisamos extrair mais alguma coisa, visto que duplicamos 'urlize'? Também em que versão isso está resolvido? Além disso, ótimo! Yay!

Isso não parece estar corrigido no 1.7.1, então 1.7.2 ou 1.8? Este é o comportamento que vejo com 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'

.. e atual chefe do ramo mestre 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'

urlize_quoted_links originalmente uma cópia modificada de django.utils.html.urlize ? https://github.com/django/django/blob/master/django/utils/html.py#L255 -L352 é significativamente diferente, mas não posso dizer o motivo para a versão separada. Parece que precisa ser copiado novamente.

Sim, foi copiado, porque o original não funcionaria para links no estilo " http://example.org " que tivessem aspas simples ou duplas entre eles e não há uma substituição fácil para permitir isso. Se houver muita diferença, é provavelmente devido à mudança gradual da versão do django enquanto a nossa permaneceu a mesma.

Vamos reabrir isso para garantir que temos um tíquete de espaço reservado para garantir que isso seja tratado.

Descartando o marco sobre isso, pois há itens de maior prioridade 3.0.1.

Eu me pergunto se é possível puxar o caso de teste com falha de # 2014

Este comentário https://github.com/tomchristie/django-rest-framework/pull/2014#issuecomment -61525348 implica que esse problema foi corrigido no Django upstream. Fechando isso, mas será reaberto se alguém confirmar que o problema continua.

Só quero confirmar se está funcionando agora :)

Amei essa biblioteca, ela já está funcionando muito bem, mas ainda assim está melhorando! 👍