#28337: fetch_redirect_response from assertRedirects doesn't honor HTTP_HOST
setting in self.client.get
-------------------------------------+-------------------------------------
     Reporter:  Roland van Laar      |                    Owner:  Patrick
         Type:                       |  Jenkins
  Cleanup/optimization               |                   Status:  assigned
    Component:  Testing framework    |                  Version:  1.11
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Patrick Jenkins):

 The problem with the provided example is that under certain conditions
 assertRedirect will replay the request with different parameters than
 originally specified. The conditions necessary for this to occur are
 passing follow=False to the original client.get and also passing 'extra'
 parameters that will be interpreted as HTTP header's. Assert redirect
 (version 1.11.4:
 
https://github.com/django/django/blob/1a34dfcf797640d5d580d261694cb54e6f97c552/django/test/testcases.py#L317)
 makes an assumption that it is possible to exactly recreate the original
 request with the information that is available.

 To properly recreate the the original request it would be necessary to
 pass ALL method parameters AND all of the kwarg parameters that were
 originally passed in. This would require storing the 'extras' in the
 Client (django.test.client.py) so they could be acccessed in
 assertRedrrects and properly replayed.

 I believe this is the proper solution because it removes the assumptions
 present when assertRedirect attempts to recreate the request. Although
 this is a corner case, it is certainly acceptable for Django users to
 utilize the infinite space that is HTTP headers and provide varying logic
 depending on the values present. The downside of this implementation is
 that it bloats the Client by requiring it to store the extra parameters
 passed in. These extra parameters will rarely be used but I believe the
 tradeoff of adding properties to Client and potentially increasing memory
 footprint are small enough to warrant this change.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/28337#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ac87f0293365d242f0c7c224a843559d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to