Re: unexpected 302 response status on update by some user-agent

[e.p.c.]

What user-agent did you specify?

I found that a user-agent of "Nokia E70-2/3.0 (2.0618.07.10) SymbianOS/
9.1 Series60/3.0 Profile/MIDP-2.0 Configuration/CLDC-1.1" worked fine,
but if I shorten that to simply "Nokia" I also get the 302.

--
-ed costello

[e.p.c.]

Just to clarify my response, my tweet posted but instead of a 200 I
got a 302 with:

curl -A Nokia --user USER --data source=curl&status=Seems+like+UA=Nokia
+upsets+twitter\? --url http://twitter.com/statuses/update.json

Also get a 302 if the UA is 'xNokia'. Suspect there's a pattern match
on some subset of MIDP browsers (though I didn't get the 302 when
posting with the longer UA string noted in my post).
--
-ed costello

[sugree]

Below are my user-agent.

SonyEricssonW810i/R4EA Browser/NetFront/3.3 Profile/MIDP-2.0
Configuration/CLDC-1.1

I guess the problem is the missing of "(...)".

[sugree]

There are something weird happened in update api. http://twitter.com/statuses/update.format
will response with 302 if user-agent is not curl. For example

curl -v -u username -d status=test302 http://twitter.com/statuses/update.json

> POST /statuses/update.json HTTP/1.1
> Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> User-Agent: curl/7.18.0 (i486-pc-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.1
> Host: twitter.com
> Accept: */*
> Content-Length: 14
> Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 200 OK
< Date: Mon, 07 Apr 2008 06:42:47 GMT
< Server: hi
< Status: 200 OK
< P3P: CP="NOI DSP COR NID ADMa OPTa OUR NOR"
< X-Runtime: 0.02310
< ETag: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
< Cache-Control: private, max-age=0, must-revalidate, max-age=300
< Content-Type: application/json; charset=utf-8
< Content-Length: 464
< Set-Cookie:
_twitter_sess=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
domain=.twitter.com; path=/
< Via: 1.1 twitter-web008.twitter.com
< Expires: Mon, 07 Apr 2008 06:47:47 GMT
< Connection: close

Anyway, it returns 302 if user-agent is midp.

> POST /statuses/update.json HTTP/1.1
> Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Host: twitter.com
> Accept: */*
> Content-Length: 14
> Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 302 Moved Temporarily
< Date: Mon, 07 Apr 2008 07:13:00 GMT
< Server: hi
< Status: 302 Found
< Last-Modified: Mon, 07 Apr 2008 07:13:00 GMT
< P3P: CP="NOI DSP COR NID ADMa OPTa OUR NOR"
< Location: http://twitter.com/home
< X-Runtime: 0.01321
< Pragma: no-cache
< Cache-Control: no-cache, must-revalidate
< Content-Type: application/xhtml+xml; charaset=UTF8
< Content-Length: 89
< Expires: Sat, 26 Jul 1997 05:00:00 GMT
< Set-Cookie:
_twitter_sess=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
domain=.twitter.com; path=/
< Via: 1.1 twitter-web046.twitter.com
< Vary: Accept-Encoding
< Connection: close

The api works correctly if follow the redirection to http://twitter.com/home
but the problem is I have to read response about 4 KB HTML instead of
400 B JSON. I just don't want to waste 10 times bandwidth for nothing.
Note that J2ME applications are not allowed to change user-agent
unless they are signed.

Moreover, most J2ME clients now doesn't work correctly because of this
302 response.

[sugree]

One more thing, J2ME will automatically add "UNTRUSTED/1.0" the user-
agent.

UNTRUSTED/1.0 SonyEricssonW810i/R4CF SonyEricssonW810i/R4EA Browser/
NetFront/3.3 Profile/MIDP-2.0
Configuration/CLDC-1.1

[sugree]

I get 302 when using your user-agent.

curl -A "Nokia E70-2/3.0 (2.0618.07.10) SymbianOS/9.1 Series60/3.0
Profile/MIDP-2.0 Configuration/CLDC-1.1" -u USER -d
'source=curl&status=test+302' --url http://twitter.com/statuses/update.json

curl -A "NokiaE70-2/3.0 (2.0618.07.10) SymbianOS/9.1 Series60/3.0
Profile/MIDP-2.0 Configuration/CLDC-1.1" -u USER -d
'source=curl&status=test+302' --url http://twitter.com/statuses/update.json

Would you please try again?

[Andy Bilodeau]

Have you tried moving the -d to be the first switch in the curl
statement. That shouldn't matter but it's what was causing me grief.

Good luck.

--
Andy Bilodeau (andycaster)
http://andycast.net

[sugree]

I tried to move "-d" as you suggested with no luck.

curl -d 'source=curl&status=test+302' -A "NokiaE70-2/3.0
(2.0618.07.10) SymbianOS/9.1 Series60/3.0 Profile/MIDP-2.0
Configuration/CLDC-1.1" -u USER --url http://twitter.com/statuses/update.json

curl -d 'source=curl&status=test+302' -A "Nokia E70-2/3.0
(2.0618.07.10) SymbianOS/9.1 Series60/3.0 Profile/MIDP-2.0
Configuration/CLDC-1.1" -u USER --url http://twitter.com/statuses/update.json

[twibble]

Alex,

I also get complaints of people using my twibble mobile client (http://
www.twibble.de/twibble-mobile). A J2ME client should really not get a
302 after a successful post. Is there any news on that?

Best,
@twibble

On Apr 7, 3:58 pm, sugree <sug...@gmail.com> wrote:
> There are something weird happened in update api.http://twitter.com/statuses/update.format

> will response with 302 if user-agent is not curl. For example
>

> curl -v -u username -d status=test302http://twitter.com/statuses/update.json

> The api works correctly if follow the redirection tohttp://twitter.com/home

[sugree]

Any news in this issue? Is 302 expected to happen regularly?

Sugree

On Apr 14, 1:11 am, twibble <thilo.horstm...@gmail.com> wrote:
> Alex,
>

> I also get complaints of people using my twibble mobile client (http://www.twibble.de/twibble-mobile). A J2ME client should really not get a

[Alex Payne]

If you're hitting a URL that redirects, yes...

--
Alex Payne
http://twitter.com/al3x

[sugree]

Does it mean mobile applications always get 302 because of user-agent
"Profile/MIDP-2.1 Configuration/CLDC-1.1"? I tested this problem in
curl and it works as long as user-agent is curl. I always get 302 to
http://twitter.com/home when I specify user-agent similar to real
phone.

curl -v -u username -A "Profile/MIDP-2.1 Configuration/CLDC-1.1" -d
status=test302 http://twitter.com/statuses/update.json

As a result, the application will get result in html format which is
big and useless. Is this a normal behavior? Anyway, I expect to get
200 and status id for later use.

sugree

[twibble]

Alex, honestly I don't think the API behaves correctly in the case of
MIDP user agents. If you send a request to the correct URI you should
not get a 302 (the tweet is accepted and propagated correctly by the
twitter api, thats not a 302!). MIDP clients should get a 200 in case
of a successful status update just like any other user agent. There is
also no indication in the API docs that MIDP clients are handled
differently.

Best,
Thilo

[Alex Payne]

Indeed, we don't have any special logic for any sort of client.

--
Alex Payne
http://twitter.com/al3x

[twibble]

this means you are going to fix it?

On 2 Mai, 19:58, "Alex Payne" <a...@twitter.com> wrote:
> Indeed, we don't have any special logic for any sort of client.
>

[Alex Payne]

We'll look into it.

--
Alex Payne
http://twitter.com/al3x

[sugree]

Thank you very much.