Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin1!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sat, 16 Nov 2013 20:38:43 +0100
From: Laszlo Nagy <gandalf@shopzeus.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Why tornado.web.RequestHandler.arguments.get is binary?
Content-Type: multipart/alternative; boundary="------------010301040909060809050603"
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2731.1384630731.18130.python-list@python.org>
Lines: 76
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:59648

This is a multi-part message in MIME format.
--------------010301040909060809050603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I believe most data passed in URLs are character data. RFC 2986 also 
suggest that the standard should be percent encoded UTF-8:

> The generic URI syntax mandates that new URI schemes that provide for 
> the representation of character data in a URI must, in effect, 
> represent characters from the unreserved set without translation, and 
> should convert all other characters to bytes according to UTF-8 
> <http://en.wikipedia.org/wiki/UTF-8>, and then percent-encode those 
> values. This requirement was introduced in January 2005 with the 
> publication of RFC 3986 <http://tools.ietf.org/html/rfc3986>. URI 
> schemes introduced before this date are not affected. [1]

It is somewhat confusing that URI may be used to represent binary data. 
More specifically, http and https URLs contain textual data in almost 
all cases. When it is textual, it must be in UTF-8 (as dictated by the 
RFC). So what is the reason in arguments.get returning binary data?


[1] http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_in_a_URI


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--------------010301040909060809050603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I believe most data passed in URLs are character data. RFC 2986 also
    suggest that the standard should be percent encoded UTF-8:<br>
    <br>
    <blockquote type="cite">The generic URI syntax mandates that new URI
      schemes that provide for the representation of character data in a
      URI must, in effect, represent characters from the unreserved set
      without translation, and should convert all other characters to
      bytes according to <a href="http://en.wikipedia.org/wiki/UTF-8"
        title="UTF-8">UTF-8</a>, and then percent-encode those values.
      This requirement was introduced in January 2005 with the
      publication of <a class="external mw-magiclink-rfc"
        rel="nofollow" href="http://tools.ietf.org/html/rfc3986">RFC
        3986</a>. URI schemes introduced before this date are not
      affected. [1]<br>
    </blockquote>
    <br>
    It is somewhat confusing that URI may be used to represent binary
    data. More specifically, http and https URLs contain textual data in
    almost all cases. When it is textual, it must be in UTF-8 (as
    dictated by the RFC). So what is the reason in arguments.get
    returning binary data?<br>
    <br>
    <br>
    [1]
    <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_in_a_URI">http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_in_a_URI</a><br>
    <br>
  <br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by <b>MailScanner</b>, and is
<br />believed to be clean.
</body>
</html>

--------------010301040909060809050603--