I was just playing with the client registration API and noticed that the following valid request fails. The client I'm using is from the httpie package.

http --form --verbose POST http://127.0.0.1:6543/api/client/register type=client_associate application_type=native
POST /api/client/register HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, compress
Content-Length: 45
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Host: 127.0.0.1:6543
User-Agent: HTTPie/0.8.0

type=client_associate&application_type=native

HTTP/1.0 400 BAD REQUEST
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 33
Content-Type: application/json
Date: Tue, 19 Jan 2016 12:31:30 GMT
Server: PasteWSGIServer/0.5 Python/2.7.6
Set-Cookie: mediagoblin_csrftoken=12864927827420732302; HttpOnly; Path=
Vary: Cookie

{
    "error": "Unknown Content-Type"
}

It should succeed like this:

HTTP/1.0 200 OK
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 120
Content-Type: application/json
Date: Tue, 19 Jan 2016 12:32:00 GMT
Server: PasteWSGIServer/0.5 Python/2.7.6
Set-Cookie: mediagoblin_csrftoken=726380659778734454; HttpOnly; Path=
Vary: Cookie

{
    "client_id": "F5lY7pUrmL9ytOjF3RW1md", 
    "client_secret": "yAce42AR3a8SGUSiJDp4GbEaYB8xBQoktNU5ZjlpmWO", 
    "expires_at": 0
}

This looks to be caused by the content-type parsing function not being aware of extra options like Content-Type: application/x-www-form-urlencoded; charset=utf-8, since the simpler case works Content-Type: application/x-www-form-urlencoded.

Attaching a patch including tests for the current code paths plus one with header options.

Running under python3, I upload a plain text file contains:

oooo
####
====
zzzz

Then view it in the browser, I get:

<div class="ascii-wrapper">
  <pre>b'oooo\n####\n====\nzzzz\n'</pre>
</div>

I think the correct result should be a multi-line block.

I can get it by using media.media_files['unicode']).read().decode('utf-8') in ascii.html, but this may not suitable for python2?

I noticed when debugging #5391 that migrations were forced to use SQLite which was defined in alembic.ini. I've pushed a fix for this which sets that option based on mediagoblin.ini however we shouldn't need to do this. We're providing a session on the manager which seems to be completely ignored, this leads to misleading code.

We need to decide between these two options:

1. We remove the session from AlembicMigrationManager to make it obvious alembic will internally open a new one
2. We make it so Alembic uses our database connection/session we've provided so it doesn't open another.

The way the code looks having a database connection we've setup but (seemingly) not using it is misleading and probably why it wasn't spotted earlier.