Custom Query (1168 matches)
Results (46 - 48 of 1168)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1049 | fixed | API Location object should have 'displayName' attribute | ||
Description |
API Location object should have the 'name' attribute renamed to 'displayName'
current:
expected:
|
|||
#27 | fixed | API Support for Mobile Uploads | ||
Description |
This might be a bit broad and/or already considered elsewhere, but having API support to upload media from third-party clients (especially on mobile computers) would be a killer feature. For example, on my N900, Maemo has share plugins which support Flickr, Twitpic, etc., and integrate well into the build in camera software. StatusNet implemented the Twitter API to allow for broad support, but I'm only familiar with Flickr, not so much Picasa or Deviant Art or other platforms. Would it make sense to implement (parts of) the Flickr API here to benefit from that same kind of support? Is there another API to consider? Or does it make more sense to create something new? `http://www.flickr.com/services/api/ <http://www.flickr.com/services/api/>`_ The feature request end goal is having some kind of API support for third-party upload clients, especially on mobile devices. Not sure if this has been considered, or what the best way to do this is. |
|||
#5397 | fixed | API client registration fails if Content-Type has options | ||
Description |
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 Attaching a patch including tests for the current code paths plus one with header options. |