UnicodeEncodeError on redirect to non-ASCII Location

#11638 closed as a dup.

Ok, 11638 was closed. It's not necessarily relative path. Imagine what would be if you redirect to a file in russian utf-8:

# -*- coding: utf-8 -*- path = '/var/www/filez/site_media/upload/alecs/отпуск-2009-ОРС.pdf'.decode('utf8') return HttpResponseRedirect?(path)

UnicodeEncodeError? at /file/365d13241be1e1a3ac00523a5deddec4f577e01f813ded539bcbac32

('ascii', u'/var/www/filez/site_media/upload/alecs/\u043e\u0442\u043f\u0443\u0441\u043a-2009-\u041e\u0420\u0421.pdf', 39, 45, 'ordinal not in range(128)')

BlindHunter?, would you mind using the wiki formatting - and, what is more important, the "Preview" button? Your text is hardly readable and if I were a Django developer, I would just disregard it.

It seems to me that you well-formed message is disregarded for more than two weeks ;) All the peculiarities and moments are important for a real developer. I'll try to use wikiformatting in my future posts.

Update on this ticket:

1) The proposed workaround does not work anymore in Django 1.1. Use the following:

def myview(request):
    print request.path # '/info/Интеграция/'
    return HttpResponseRedirect('?edit=1') # crashes
    return HttpResponseRedirect(request.path + '?edit=1') # still crashes
    return HttpResponseRedirect(request.build_absolute_uri('?edit=1')) # doesn't crash, but violates DRY principle

2) I disregard my words about "moving the call to iri_to_uri blah-blah-blah..", they don't make sense, as that's what [10539] was actually about.

3) Still, I consider [10539] to be the cause of the problem. I can see two ways to fix the issue:

a) a special case in HttpResponse.setitem to handle 'Location' header properly (attached)
b) practically revert [10539], but instead of calling iri_to_uri in each and every case (as it was before [10539]), call fix_location_header instead. That is worse, as fix_location_header will be called twice then.

added a special rule in HttpResponse.setitem

Perhaps (a) can be improved to apply fix_location_header logic, and then we'll don't need the fix_location_header middleware at all.

The problem is in value.encode('us-ascii') - this codec can't encode my url as it contains a file named in russian. A serious bug :( In order to skip encoding check you can override in HttpResponseRedirect? method _convert_to_ascii:

def _convert_to_ascii(self, *values):
        """Converts all values to ascii strings."""
        for value in values:
            if isinstance(value, unicode):
                try:
                    value = value.encode('us-ascii')
                except:
                    pass
            else:
                value = str(value)
            if '\n' in value or '\r' in value:
                raise BadHeaderError("Header values can't contain newlines (got %r)" % (value))
            yield value

Patch to support IRI in redirections.

A small patch of mine that enables doing redirection using unicode IRI like Mr. Snowman

>>> HttpResponseRedirect(u"http://müller.de/")
Location: http://xn--mller-kva.de/

I also think that URLField should accept such IRI, maybe we can create a new one and call it IRIField.

The problem is in value.encode('us-ascii')

The problem is NOT in value.encode. That is absolutely correct to encode the response headers in ASCII as required by RFC1915. The problem is that the URL in "Location" field is not automatically urlencoded, as anyone would expect.

Unicode in the bug title should read non-ascii. Remember, it's possible to encode urls in other encodings besides Unicode.

IanLewis?, you are mistaken. Unicode is a character set, not an encoding. That doesn't make sense to encode urls in ... Unicode. URLs can be encoded in UTF8, CP1251 or any other encoding which are all mappings from a character set (Unicode) to particular byte strings. (Getting into details, URLs are actually encoded twice -- first from Unicode to byte strings, then from byte strings to lower-ASCII strings using the %XX notation).

This ticket title mentions Unicode URLs and I consider that to be perfectly fine.

Closing #11921 as a dupe. Removed 'relative' from the summary since that was overly specific. Also, put non-ASCII in the summary since the problem is not use of Unicode but rather the presence of non-ASCII characters. A Unicode string with all ASCII chars works fine.

My question here is whether the translation should be completely transparent, i.e.

return HttpResponseRedirect(u'/áíé/');
return HttpResponseRedirect(u'http://áíé/');

should just work (but I've read on Python pages that there are some problems in automatic conversion), or is it responsibility of the developer, so you have

return HttpResponseRedirect(iri_to_uri(u'/áíé/'));

Anyway, the Django methods should just work, so the following should work I think (at least the first case):

return HttpResponseRedirect(request.get_full_path());
return HttpResponseRedirect(request.path);

The ticket11522_puny_code.patch fixed the problem for me. Is it possible to apply this to the django trunk ?

Thank you.

simple patch worked in my case. looking forward to fix this

Got this problem too, any fix would be welcome. I'm going with simple_fix.diff for now.

Same problem here, it would be welcome to merge the patch with trunk.

have this problem to, pls fix it

(In [12660]) [1.1.X] Fixed #11522: Restored ability of http redirect responses to correctly handle redirect locations with non-ASCII chars.

r12659 from trunk.