Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SchemaGenerator outputs non-functional URLs when using Django 2.0 path() #5686

Closed
5 of 6 tasks
tiltec opened this issue Dec 19, 2017 · 6 comments
Closed
5 of 6 tasks

Comments

@tiltec
Copy link
Contributor

tiltec commented Dec 19, 2017

Checklist

  • I have verified that that issue exists against the master branch of Django REST framework.
  • I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
  • This is not a usage question. (Those should be directed to the discussion group instead.)
  • This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
  • I have reduced the issue to the simplest possible case.
  • I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Create a Django 2.0 URLconf and generate a schema from it.

urlpatterns = [
  path('example/', ExampleListView.as_view()),
  path('example/<int:pk>/', ExampleDetailView.as_view()),
]

Expected behavior

Get a schema with urls /example/ and /example/{id}/

Actual behavior

Got /example\\/ and /example\\/{id}\\/.

Ref: marcgibbons/django-rest-swagger#718

Background

Django 2.0 auto-escapes the string passed into path(), see this piece of code

Possible solution

SchemaGenerator could undo this escaping when building the schema, I'm working on PR that does this.

@tiltec
Copy link
Contributor Author

tiltec commented Dec 19, 2017

SchemaGenerator uses simplify_regex from django.contrib.admindocs, I wonder if they have the same problem and it should be fixed there?

EDIT: No, everything fine there as they call str on the pattern before passing it to simplify_regex.

@axnsan12
Copy link
Contributor

@tiltec I don't see how calling str helps? care to elaborate?

@axnsan12
Copy link
Contributor

Ah, I see now, django gets around this by calling str() directly on the RoutePattern/RegexPattern object; the result of str(RoutePattern) is a path() route, so simplify_regex does not affect it at all. For RegexPattern, simplify_regex transforms it into something that looks like str(RoutePattern), and they then treat both kinds like RoutePatterns (i..e path() routes)

django-rest-framework does it in the opposite way, and grabs the regex from the RoutePattern and treats both kinds as regexes, which fails because the RoutePattern regex is heavily escaped and not handled by simplify_regex.

@tiltec
Copy link
Contributor Author

tiltec commented Dec 19, 2017

Exactly! RoutePattern.__str__() returns the original route, which is not a regex. That doesn't matter for simplify_regex() apparently...

@axnsan12
Copy link
Contributor

axnsan12 commented Dec 19, 2017

For what it's worth, this seems to be the same problem as #5675. I made an attempt at a naive fix for the way django-rest does it (here), but filpping it around to the same treatment as django would probably make more sense.

@tiltec
Copy link
Contributor Author

tiltec commented Dec 19, 2017

True, I didn't notice this one. Close here and move discussion to the other one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants