update_with_media fails with larger images (still below max)


#1

Recently we have been seeing failures to post larger images to twitter. These are still under the max size allowed, but perhaps over 600k. It seems like it might be a problem with the HTTP Continue functionality. I’m wondering if some sort of back-end changes were made with how images are received that are causing problems.

During investigation we noticed that curl was automatically putting ‘Expect: 100-continue" in the headers before, and twitter was responding with a 100 response, which curl wasn’ automatically handle. So we disabled that with a "Expect: " injected into the headers, but now we seem to be getting ssl write errors.

Some details:
• We are using php/curl & tmhOAuth; upgraded to recent curl (7.21.7) and tmhOAuth (0.8.3)
• Smaller images work fine, as do all of our other REST calls
• We are using SSL

The Request Headers, dumped from the Curl Response:

POST /1.1/statuses/update_with_media.json HTTP/1.1
User-Agent: tmhOAuth 0.8.3+SSL - //github.com/themattharris/tmhOAuth
Host: api.twitter.com
Accept: */*
Accept-Encoding: deflate, gzip
Authorization: OAuth oauth_consumer_key="xxx", oauth_nonce="xxx", oauth_signature="xxx", oauth_signature_method="HMAC-SHA1", oauth_timestamp="xxx", oauth_token="xxx-xxx", oauth_version="1.0"
Content-Length: 1107932
Content-Type: multipart/form-data; boundary=----------------------------4b85d0fded9f

The response we get back seems to be a failure to write:

    [error] => select/poll returned error
    [errno] => 55

or

    [error] => SSL_write() returned SYSCALL, errno = 104
    [errno] => 55

Any thoughts on changes that were made that might be causing this, or if someone has an idea how to get curl to deal with 100 continue better would be very helpful.

Thanks!


#2

We’re seeing the same thing happen within our application. (bufferapp.com). This seems to be sporadic for us, as the same image tried will sometimes succeed and sometimes fail.


#3

I’m glad to hear that we’re not the only ones. I haven’t found a workaround yet, though it does work more consistently from a dev environment mac laptop, which makes me believe there may be some libraries that work better with the change.


#4

Our contact on the twitter development team has mentioned this, so I think this is being worked on :slight_smile:

“No worries, this is indeed something we have been seeing in the last 24 hours, we are currently investigating the issue, I will get back to you once I have more details.”


#5

That’s good to hear, thanks!


#6

Can you guys do a test for me? I have been investigating this one but I am a bit stumped… Can you test it with twurl, as per https://dev.twitter.com/docs/uploading-media with the -t argument? Tell me if you see anything weird in there (compared to when you call it from your code), this will help me understand a bit more where the issue could be.


#7

@froginthevalley I did this with a file that was crashing, and that -t sure spits out A LOT.

The output was (snipped in the middle):

POST /1.1/statuses/update_with_media.json HTTP/1.1\r\nAccept: /\r\nUser-Agent: OAuth gem v0.4.7\r\nContent-Type: multipart/form-data, boundary=“00Twurl3252746936940725lruwT99”\r\nAuthorization: OAuth oauth_body_hash=“xxx”, oauth_consumer_key=“xxx”, oauth_nonce=“xxx”, oauth_signature=“xxx”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“1391132132”, oauth_token=“11989682-xxx”, oauth_version=“1.0”\r\nConnection: close\r\nHost: api.twitter.com\r\nContent-Length: 1107906\r\n\r\n"
<- "–00Twurl3252746936940725lruwT99\r\nContent-Disposition: form-data; name=“status”\r\n\r\n@froginthevalley This is a test from @covati\r\n–00Twurl3252746936940725lruwT99\r\nContent-Disposition: form-data; name=“media[]”; filename=“2014-01-30A6035_2014-01-29_22-13-06_6800c57d332f740055ce1ec2cf0aae55.jpg”\r\nContent-Type: application/octet-stream\r\n\r\n\xFF\xD8\xFF\xE0\x00\x10JFIF\x00\x01\x02\x00\x00d\x00d\x00\x00\xFF\xEC\x00\x11Ducky\x00\x01\x00\x04\x00\x00\x00<\x00\x00\xFF\xEE\x00\x0EAdobe\x00d\xC0\x00\x00\x00\x01\xFF\xDB\x00\x84\x00\x06\x04\x04\x04\x05\x04\x06\x05\x05\x06\t\x06\x05\x06\t\v\b\x06\x06\b\v\f\n\n\v\n\n\f\x10\f\f\f\f\f\f\x10\f\x0E\x0F\x10\x0F\x0E\f\x13\x13\x14\x14\x13\x13\x1C\e\e\e\x1C\x1F\x1F\x1F\x1F\x1F\x1F\x1F\x1F\x1F\x1F\x…

— snip for 10s of thousands of lines of image output —
…x01\xC8P[\xF8\nJ\x04\xE4\x9De\x03\xA21\xFBV\x8A\xCB\u{408}?\xFF\xD9\r\n–00Twurl3252746936940725lruwT99–\r\n"
Conn close because of error end of file reached
/usr/lib64/ruby/1.9.1/openssl/buffering.rb:145:in sysread_nonblock': end of file reached (EOFError) from /usr/lib64/ruby/1.9.1/openssl/buffering.rb:145:inread_nonblock’
from /usr/lib64/ruby/1.9.1/net/protocol.rb:135:in rbuf_fill' from /usr/lib64/ruby/1.9.1/net/protocol.rb:116:inreaduntil’
from /usr/lib64/ruby/1.9.1/net/protocol.rb:126:in readline' from /usr/lib64/ruby/1.9.1/net/http.rb:2219:inread_status_line’
from /usr/lib64/ruby/1.9.1/net/http.rb:2208:in read_new' from /usr/lib64/ruby/1.9.1/net/http.rb:1191:intransport_request’
from /usr/lib64/ruby/1.9.1/net/http.rb:1177:in request' from /usr/lib64/ruby/1.9.1/net/http.rb:1170:inblock in request’
from /usr/lib64/ruby/1.9.1/net/http.rb:627:in start' from /usr/lib64/ruby/1.9.1/net/http.rb:1168:inrequest’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/oauth_client.rb:115:in perform_request_from_options' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/request_controller.rb:13:inperform_request’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/request_controller.rb:9:in dispatch' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/abstract_command_controller.rb:7:indispatch’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/cli.rb:38:in dispatch' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/cli.rb:21:inrun’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/bin/twurl:4:in <top (required)>' from /usr/bin/twurl:19:inload’
from /usr/bin/twurl:19:in `’


#8

I tried it again with a smaller file, this time it seemed to finish the image upload, but then hung for a 30-45 seconds and then I got this (with the trailing end of the image upload included):

…\xFEz\a\x93\xA9\xA0tt\x14\v@/\u{583}(\x12\x83\xFF\xD9\r\n–00Twurl718403224066334914lruwT99–\r\n"

Conn close because of error end of file reached
/usr/lib64/ruby/1.9.1/openssl/buffering.rb:145:in sysread_nonblock': end of file reached (EOFError) from /usr/lib64/ruby/1.9.1/openssl/buffering.rb:145:inread_nonblock’
from /usr/lib64/ruby/1.9.1/net/protocol.rb:135:in rbuf_fill' from /usr/lib64/ruby/1.9.1/net/protocol.rb:116:inreaduntil’
from /usr/lib64/ruby/1.9.1/net/protocol.rb:126:in readline' from /usr/lib64/ruby/1.9.1/net/http.rb:2219:inread_status_line’
from /usr/lib64/ruby/1.9.1/net/http.rb:2208:in read_new' from /usr/lib64/ruby/1.9.1/net/http.rb:1191:intransport_request’
from /usr/lib64/ruby/1.9.1/net/http.rb:1177:in request' from /usr/lib64/ruby/1.9.1/net/http.rb:1170:inblock in request’
from /usr/lib64/ruby/1.9.1/net/http.rb:627:in start' from /usr/lib64/ruby/1.9.1/net/http.rb:1168:inrequest’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/oauth_client.rb:115:in perform_request_from_options' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/request_controller.rb:13:inperform_request’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/request_controller.rb:9:in dispatch' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/abstract_command_controller.rb:7:indispatch’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/cli.rb:38:in dispatch' from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/lib/twurl/cli.rb:21:inrun’
from /usr/lib64/ruby/gems/1.9.1/gems/twurl-0.9.1/bin/twurl:4:in <top (required)>' from /usr/bin/twurl:19:inload’
from /usr/bin/twurl:19:in `’

So it seems to be failing no matter what there.


#9

We are experiencing this same issue. However it has also happened for us on images as small as 35k. The bulk of the failures have been on items ranging from 390k - 1.2m.


#10

Agreed, my earlier research showed that smaller worked, but it seems to just work more often if they are smaller. Thanks for chiming in on this!


#11

It should be solved now, we deployed the fix a few minutes ago. Can you guys test and confirm with me that everything is back to normal? Thanks!


#12

Fantastic! That worked great, here is my tweet from twurl:

And here is one through our app:

Lookin good guys, thanks!


#13

Looks good on our side also, 38 tweets with images posted successfully.