GET-parameters in `path` argument of `django.test.client.Client.get`

[lagunov.vladimir@…]

Sometimes we need to send with Client query on URL that already contains GET parameters. In such situation method get of Client totally replaces parameters from URL and sends only parameters from argument data. This behavior isn't obvious and it would be more convenient for programmer if get will append parameters from data to query instead of replacing it.

[Claude Paroz]

The current behaviour is explicitely tested:

​https://github.com/django/django/blob/master/tests/regressiontests/test_client_regress/tests.py#L822

It was introduced in:

​https://github.com/django/django/commit/95d8c0619a

and documented:

​https://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.Client.get
("If you provide a URL with both an encoded GET data and a data argument, the data argument will take precedence.")

To me, your proposal makes sense. But I'd like to get the opinion of Russell (committer of changeset above) before moving on.

P.S. Please provide patches as unified diff format.

[Russell Keith-Magee]

For context - there's a bit of history in play here. Once upon a time, you couldn't provide GET arguments in the query argument; you could only use the data argument. The test client was then modified to allow you to provide both a URL encoded query, and a data argument. This was done for two reasons:

1) Convenience in testing simple GET requests

2) Handling POSTs to URLs that contained query argument (e.g., POST "foo=whiz; pork=spam" to ​http://example.com/?foo=bar ).

The browser should always be the reference point here; So - What does a browser do if you submit a form using GET to ​http://example.com/?whiz=bang with a form payload of 'foo=whiz; pork=spam'? *That* is what the test client should do.

From my testing, if you use GET to submit a form with 'foo=whiz; pork=spam' to .?whiz=bang, the whiz=bang part is lost; you only get the foo and pork keys. This matches the existing behavior of the test client (allowing for the historical usage where GET arguments couldn't be passed in on the query itself).

So - I'm satisfied that the existing behavior is correct, and I'm marking the ticket invalid; however, if someone can make a case for another interpretation, feel free to reopen the ticket.