X-rate-limit-... headers missing when using POST

[benjaminhelgert]

Hey guys,

IMPORTANT EDIT:
I just figured out that using POST does not decrease the x-rate-limit-remaining value of users/lookup.json, which means it might be exploitable.

ORIGINAL MESSAGE:
I’m trying to use the users/lookup.json method of the REST-API v1.1 but stumbled across a weird issue.
When I use GET, all the x-rate-limit-headers are contained in the response of the API.
But as soon as I use POST, the x-rate-limit-headers are not contained in the API-response anymore.

I really need to use POST though, because my app looks up 100 users per request, and for that many lookups the docs strongly encourage using POST instead of GET:
https://dev.twitter.com/rest/reference/get/users/lookup

The status code of the response is 200 in both cases and the looked up users are correctly retrieved by my app as well. I am using an application only authentication and I also switched permissions of my app from ‘Read’ to ‘Read, write, and direct messages’, but to no avail.

I am looking forward to your answers.

Best
Benjamin

[isaach]

I tried

twurl -t -X POST -d "screen_name=isaach" "/1.1/users/lookup.json"

as well as

twurl -t "/1.1/users/lookup.json?screen_name=isaach"

and both showed the X-Rate-Limit-* headers in the response, as well as correctly decrementing the X-Rate-Limit-Remaining value.

Can you reproduce the behavior you describe with twurl? Or can you help me reproduce it?

[benjaminhelgert]

Hi Isaach,

Sorry for the delayed repsonse.

I use the “Advanced Rest Client App” for Chrome and unfortunately the problem still persists:

Advanced REST client

In the field “Raw Headers” I use:
Authorization: Bearer [MyBearerToken]
Host: api.twitter.com
X-Target-URI: https://api.twitter.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8

For “Raw Payload” I type:
screen_name=isaach

I haven’t tried twurl yet, is it only available for Linux or for Windows 7 as well?

Best
Benjamin

[andypiper]

twurl is a command-line tool written in Ruby, and should work just fine on Windows if you have a Ruby runtime available. There’s no installer though, so you may find it slightly fiddly to set up if you’re not familiar with these kinds of tools.

[andypiper]

I use the “Advanced Rest Client App” for Chrome

I’ve just tried using this tool myself and I can confirm that using both the POST and GET methods return a rate limit header - here’s the example response from my POST, cut-and-pasted from that Chrome tool:

status: 200 OK
version: HTTP/1.1
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-encoding: gzip
content-length: 1286
content-type: application/json;charset=utf-8
date: Wed, 15 Oct 2014 12:58:57 UTC
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Wed, 15 Oct 2014 12:58:57 GMT
pragma: no-cache
server: tsa_b
status: 200 OK
strict-transport-security: max-age=631138519
x-access-level: read-write-directmessages
x-connection-hash: d9c68ae1aa576a11f3b05b78501a4012
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-rate-limit-limit: 180
x-rate-limit-remaining: 176
x-rate-limit-reset: 1413378563
x-transaction: a31ec1fa6412005b
x-xss-protection: 1; mode=block

[benjaminhelgert]

I see, I guess I’ll stick to the Chrome tool until I have the patience to set up twurl.

[benjaminhelgert]

As I just noticed, the raw header one inputs in the field “Raw Headers” is not the complete header the chrome app sends.

The complete header as shown at “Request headers” reads as follows:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo
X-Target-URI: https://api.twitter.com
Authorization: Bearer [MyBearerToken]
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: /
Accept-Encoding: gzip,deflate
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: [MyCookieData]

The at “Response headers” I get:

status: 200 OK
version: HTTP/1.1
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-encoding: gzip
content-length: 1289
content-type: application/json;charset=utf-8
date: Wed, 15 Oct 2014 15:29:03 UTC
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Wed, 15 Oct 2014 15:29:03 GMT
pragma: no-cache
server: tsa_b
status: 200 OK
strict-transport-security: max-age=631138519
x-access-level: read
x-connection-hash: 2f46ed1a5d9a5144730415fb32071854
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-transaction: d9f116e52ba551d1
x-xss-protection: 1; mode=block

The JSON reply starts with:

[1]
0: {
id: 7852612
id_str: "7852612"
name: "Isaac Hepworth"
screen_name: "isaach"
location: "Boulder, CO"
profile_location: null

My Twitter app I send the request from is called “bookular” and registered for my Twitter account with Twitter User ID:
72588552

I hope this helps reproducing the behavior. If you have any suggestions, what further information could shed light on why it occurrs, just let me now.

Best
Benjamin