mechanize and Ruby multipart/form-data - content transfer encoding - ruby

I am trying to dispatch a multipart/form-data POST request to a remote server using mechanize 2.7.3 to automate some interactions with a remote server. Unfortunally there is no usable <form>, so I have to issue the POST directly. Luckily, mechanize recognizes what I am up to anyway, but the server doesn't accept the response:
c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/mechanize-2.7.3/lib/mechanize/http/agent.rb:308: in `fetch': 400 => Net::HTTPBadRequest for http://REDACTED/api/resources -- unhandled response (Mechanize::ResponseCodeError)
from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/mechanize-2.7.3/lib/mechanize.rb:1281:in `post_form'
from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/mechanize-2.7.3/lib/mechanize.rb:502:in `post'
from thing.rb:38:in `upload'
Here's what mechanize logging output looks like during the request in question:
D, [2014-05-13T12:40:34.580906 #3456] DEBUG -- : query: "--cNPsKCeBSrPGUwxyjMze\r\nContent-Disposition: form-data; name=\"force_create\"\r\n\r\ntrue\r\n--cNPsKCeBSrPGUwxyjMze\r\nContent-Disposition: form-data; name=\"file\"; filename=\"test.wgt\"\r\nContent-Transfer-Encoding: binary\r\n\r\nREDACTED\r\n--cNPsKCeBSrPGUwxyjMze--\r\n"
I, [2014-05-13T12:40:34.581906 #3456] INFO -- : Net::HTTP::Post: /api/resources
D, [2014-05-13T12:40:34.581906 #3456] DEBUG -- : request-header: accept => */*
D, [2014-05-13T12:40:34.581906 #3456] DEBUG -- : request-header: user-agent => Mechanize/2.7.3 Ruby/1.9.3p392 (http://github.com/sparklemotion/mechanize/)
D, [2014-05-13T12:40:34.581906 #3456] DEBUG -- : request-header: accept-encoding => gzip,deflate,identity
D, [2014-05-13T12:40:34.581906 #3456] DEBUG -- : request-header: accept-charset => ISO-8859-1,utf-8;q=0.7,*;q=0.7
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: accept-language => en-us,en;q=0.5
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: cookie => csrftoken=G4dZv6fxRMq0Y2h5yntDsJTFBeEKVFaU; sessionid=9oqufupdt6r620eyep4l4jcl6i2cxda5
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: host => REDACTED
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: referer => REDACTED/login
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: content-type => multipart/form-data; boundary=cNPsKCeBSrPGUwxyjMze
D, [2014-05-13T12:40:34.582906 #3456] DEBUG -- : request-header: content-length => 409
I, [2014-05-13T12:40:34.613906 #3456] INFO -- : status: Net::HTTPBadRequest 1.1 400 BAD REQUEST
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: date => Tue, 13 May 2014 10:33:44 GMT
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: server => Apache/2.2.15 (CentOS)
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: vary => Accept-Language,Cookie,Accept-Encoding
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: content-language => en
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: content-type => text/plain; charset=utf-8
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: content-encoding => gzip
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: content-length => 37
D, [2014-05-13T12:40:34.613906 #3456] DEBUG -- : response-header: connection => close
D, [2014-05-13T12:40:34.614906 #3456] DEBUG -- : Read 37 bytes (37 total)
D, [2014-05-13T12:40:34.614906 #3456] DEBUG -- : gzip response
This is how I do it in Ruby:
def upload(file)
agent.post(base_uri + RESOURCES_PATH, {
:force_create => true,
:file => File.new(file)
}) do … end
end
Every other interaction with the site works normally (mechanize actually even logs in first, thus the cookies). The upload also works fine in a real browser – the only discernable difference is the content transfer encoding (octet-stream instead of binary). Or maybe I am missing something here? Something vital?
Also, I can't say much about the remote server in question. I only know the site is running some sort of Python-based framework (Django, iirc).
Thanks in advance,
Manuel

I have managed to identify the culprit here. As my development machine is Windows-based, this seems to have been an issue with mechanize (or one of its dependencies) and Windows. By specifying the b (binary) part in the second argument of File.new, the problem went away on its own. tl;dr: here's how the working code fragment now looks like:
agent.post(base_uri + RESOURCES_PATH, {
:force_create => true,
:file => File.new(file, 'rb') # <-- changed
})

Related

Rails Admin POST requests cause H15 error on Heroku

I have a rails app that is working fine on Heroku, but all the POST requests coming from Rails admin are hanging for 55 seconds before causing a H15 "Idle Connection" error.
I've read that it can come from:
ActionCable not pinging the server during 55 consecutive seconds but I'm not using real time features with Rails Admin and I removed my ActionCable code to test and the problem still occurs
The server tries to return a response to a different IP than the one that initiated the call once you've configured your DNS, but I'm not, I'm not using a custom domain name, I use the my website-herokuapp.com one.
Here's the log of a POST request from my app from the admin:
2021-01-24T19:09:36.245896+00:00 app[web.1]: I, [2021-01-24T19:09:36.245747 #4] INFO -- : source=rack-timeout id=21d5a60a-a82a-4cf7-bbe1-b0254f5823c7 wait=11ms timeout=15000ms state=ready
2021-01-24T19:09:36.246186+00:00 app[web.1]: D, [2021-01-24T19:09:36.246074 #4] DEBUG -- : source=rack-timeout id=21d5a60a-a82a-4cf7-bbe1-b0254f5823c7 wait=11ms timeout=15000ms service=0ms state=active
2021-01-24T19:09:36.246456+00:00 app[web.1]: I, [2021-01-24T19:09:36.246394 #4] INFO -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] Started PUT "/admin/first_job/252990/edit" for 92.183.112.168 at 2021-01-24 19:09:36 +0000
2021-01-24T19:09:36.248487+00:00 app[web.1]: I, [2021-01-24T19:09:36.248393 #4] INFO -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] Processing by RailsAdmin::MainController#edit as HTML
2021-01-24T19:09:36.248636+00:00 app[web.1]: I, [2021-01-24T19:09:36.248524 #4] INFO -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] Parameters: {"utf8"=>"✓", "authenticity_token"=>"9QGOhotnG3BkLq6TbkXuXZgMVxJ+AinueV0oEUaVw5iaQ6DRJukISaCV4x+lcpXog9ExNYf9DB8/u/jufN6+Dg==", "first_job"=>{"company_name"=>"My company"}, "return_to"=>"https://mywebsite-staging.herokuapp.com/admin/first_job", "_save"=>"", "model_name"=>"first_job", "id"=>"252990"}
2021-01-24T19:09:36.285663+00:00 app[web.1]: D, [2021-01-24T19:09:36.285530 #4] DEBUG -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] User Load (1.5ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT $2 [["id", 307509], ["LIMIT", 1]]
2021-01-24T19:09:36.307192+00:00 app[web.1]: D, [2021-01-24T19:09:36.307039 #4] DEBUG -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] FirstJob Load (2.0ms) SELECT "first_jobs".* FROM "first_jobs" WHERE "first_jobs"."id" = $1 ORDER BY "first_jobs"."id" ASC LIMIT $2 [["id", 252990], ["LIMIT", 1]]
2021-01-24T19:09:36.312261+00:00 app[web.1]: D, [2021-01-24T19:09:36.312087 #4] DEBUG -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] (1.0ms) BEGIN
2021-01-24T19:09:36.317945+00:00 app[web.1]: D, [2021-01-24T19:09:36.317805 #4] DEBUG -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] Company Load (1.8ms) SELECT "companies".* FROM "companies" WHERE "companies"."id" = $1 LIMIT $2 [["id", 26218], ["LIMIT", 1]]
2021-01-24T19:09:36.322239+00:00 app[web.1]: D, [2021-01-24T19:09:36.322101 #4] DEBUG -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] (1.1ms) COMMIT
2021-01-24T19:09:36.323441+00:00 app[web.1]: I, [2021-01-24T19:09:36.323351 #4] INFO -- : [21d5a60a-a82a-4cf7-bbe1-b0254f5823c7] Redirected to https://mywebsite-staging.herokuapp.com/admin/first_job
2021-01-24T19:09:36.324756+00:00 app[web.1]: I, [2021-01-24T19:09:36.324674 #4] INFO -- : Completed 302 Found in 76ms (ActiveRecord: 19.6ms)
2021-01-24T19:09:36.324858+00:00 app[web.1]: I, [2021-01-24T19:09:36.324425 #4] INFO -- : source=rack-timeout id=21d5a60a-a82a-4cf7-bbe1-b0254f5823c7 wait=11ms timeout=15000ms service=79ms state=completed
2021-01-24T19:10:31.518929+00:00 heroku[router]: at=error code=H15 desc="Idle connection" method=POST path="/admin/first_job/252990/edit" host=mywebsite-staging.herokuapp.com request_id=21d5a60a-a82a-4cf7-bbe1-b0254f5823c7 fwd="92.183.112.168" dyno=web.1 connect=0ms service=55282ms status=503 bytes= protocol=https
Oh and of course, everything is working fine on my local.
Do someone has an idea?

Request "wait" time is high. Do you see any issue with this HTTP2.0 header?

In my website, only one request,(ie. the root request) is taking more time. Especially the "wait" time is high. The HTTP2.0 Header for the request that is taking more time is posted below. Do you see any issue that might cause this request to take more "wait" time?
I have just removed the domain name. Please post your thoughts. Your help would be greatly appreciated.
cache-control : max-age=0
cf-cache-status : DYNAMIC
cf-ray : 5a1adf4d010925-SEA
cf-request-id : c4e5021110925303a9200000001
content-encoding : br
content-type : text/html; charset=UTF-8
date : Thu, 11 Jun 2020 12:26:39 GMT
expect-ct : max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires : Thu, 11 Jun 2020 12:26:37 GMT
host-header : b7440e60b07ee7b80454eff108fab2118
link : <https://www.<domainname>.com/wp-json/>; rel="https://api.w.org/", <https://www.<domainname>.com/>; rel=shortlink
server : cloudflare
set-cookie : __cfduid=d775816f66f9fe58d133f15c6546544654078397; expires=Sat, 11-Jul-20 12:26:37 GMT; path=/; domain=.<domainname>.com; HttpOnly; SameSite=Lax
status :200
vary : Accept-Encoding
x-cache-enabled : False
x-proxy-cache : MISS

The debugger does not pause at the next breakpoint and trace doesn't report anything

When I use curl to post a SOAP message into message flow, it takes 9 seconds to respond. Debug won't stop at breakpoints and User Trace doesn't report anything. Meanwhile when I do the same request from Postman or SoapUI (the first message takes the same amount of time, later all messages take around 70 - 200ms) debugger and user trace work as intended. What is cause of this behavior?
IBM App Connect Enterprise 11.0.0.8
curl --trace-time output:
03:29:07.484000 * Trying <host>...
03:29:07.484000 * TCP_NODELAY set
03:29:07.531000 * Connected to <host_name> (<host>) port 7800 (#0)
03:29:07.531000 > POST /service HTTP/1.1
03:29:07.531000 > Host: <host_name>:7800
03:29:07.531000 > User-Agent: curl/7.55.1
03:29:07.531000 > Accept: */*
03:29:07.531000 > Content-Length: 508
03:29:07.531000 > Content-Type: application/x-www-form-urlencoded
03:29:07.531000 >
03:29:07.546000 * upload completely sent off: 508 out of 508 bytes
03:29:16.671000 < HTTP/1.1 200 OK
03:29:16.671000 < Cache-Control: no-cache
03:29:16.671000 < Pragma: no-cache
03:29:16.687000 < Expires: -1
03:29:16.687000 < X-AspNet-Version: 4.0.30319
03:29:16.687000 < X-Powered-By: ASP.NET
03:29:16.687000 < Date: Fri, 22 May 2020 01:29:14 GMT
03:29:16.687000 < Content-Type: text/xml; charset=utf-8
03:29:16.703000 < Server: IBM App Connect Enterprise
03:29:16.703000 < Content-Length: 243
EDIT: I'm still trying to resolve the problem - this time with help of Wireshark and user trace:
curl:
02:56:37.781000 > POST /service HTTP/1.1
after few milliseconds Wireshark detects POST message from "curl machine" - that means there are no problems with the connection
after around 10s delay SoapInput receives data. Why it takes so long?
2020-05-23 02:56:37.257076 6220 UserTrace BIP11304I: The Parser of type 'MQROOT' has been deleted from address '0x131f1312190'. This thread now has '0' cached parsers.
2020-05-23 02:56:40.591580 3684 UserTrace BIP11303I: A Parser of type 'MQROOT' has been created at address '0x131f13144a0'. This thread now has '36' cached parsers.
2020-05-23 02:56:45.143380 3684 UserTrace BIP11501I: Received data from input node 'SOAP Input'.
The input node 'SOAP Input' has received data and has propagated it to the message flow 'link'.
2020-05-23 02:56:45.143880 3684 UserTrace BIP6060I: Node 'link.SOAP Input' used parser type 'Properties' to process a portion of the incoming message of length '0' bytes beginning at offset '0'.
Fixed by restarting the machine. Any clue what exactly caused this problem?

how to download large file on G-wan?

I use G-wan download files from directory 'www' ,it can download the files size less than 16M,if the files size is 16M, the G-wan is wrong:
Signal : 11:Unknown SIGSEGV problem
Signal src : 128:.
errno : 0
Thread : 1
Code Pointer: 0000004081a8 (module:gwan, function:??, line:0)
Access Address: 000000000000
Registers : EAX=7f1dbc0afa4e CS=00000033 EIP=0000004081a8 EFLGS=000000010287
EBX=7f1dc24af000 SS=d5ab0400 ESP=7f1dd59acd30 EBP=7f1dbc0afa4e
ECX=ffe3e5a1746a4230 DS=d5ab0400 ESI=1c997c47a33a4e FS=00000033
EDX=1c1a5e8b984000 ES=d5ab0400 EDI=7f1dbc0afa3e CS=00000033
Module :Function :Line # PgrmCntr(EIP) RetAddress FramePtr(EBP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Segmentation fault
thanks for Gil.
Os: debian 7,rhel6.4
dwonload the file size is 80M ,file:0.0.0.0_8080/#0.0.0.0/www/MFC-7340-inst-B2-zh.EXE.this is trace content:
Wed, 14 Aug 2013 02:57:36 GMT: start
Wed, 14 Aug 2013 02:58:00 GMT 12 127.0.0.1
GET /MFC-7340-inst-B2-zh.EXE HTTP/1.1^M
Host: localhost:8080^M
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Firefox/17.0 Iceweasel/17.0.8^M
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
Accept-Language: en-US,en;q=0.5^M
Accept-Encoding: gzip, deflate^M
Connection: keep-alive^M
Cookie: SESS49960de5880e8c687434170f6476605b=iOQ_BgGEgAWbhB9zA0U5jZbEOXzmu3nkzhyBW00GJGM; Drupal.tableDrag.showWeight=0; Drupal.toolbar.collapsed=1; MOIN_SESSION_800_ROOT=8a77c4a58fefc1ad6b6830b5bc51ca680a480bae^M
^M
Wed, 14 Aug 2013 02:58:02 GMT: signal 11: Unknown SIGSEGV problem
source : 128:Kernel
thread : 0/2
state : SEND
client : 127.0.0.1:58472
request : /MFC-7340-inst-B2-zh.EXE
----------------
----------------
Signal : 11:Unknown SIGSEGV problem
Signal src : 128:.
errno : 0
Thread : 0
Code Pointer: 0000004081a8 (module:gwan, function:??, line:0)
Access Address: 000000000000
Registers : EAX=7f85482fd0c0 CS=00000033 EIP=0000004081a8 EFLGS=000000010293
EBX=7f8565501000 SS=6cd00400 ESP=7f856cbfcd30 EBP=7f85482fd0c0
ECX=ffeea9eeb46863d5 DS=6cd00400 ESI=11d59693c9ef4b FS=00000033
EDX=1156114b9a1e8b ES=6cd00400 EDI=7f85482fd0b0 CS=00000033
Module :Function :Line # PgrmCntr(EIP) RetAddress FramePtr(EBP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
G-WAN has been used to serve much larger file sizes. Could you specify the exact file size you have used so we can try to duplicate this issue?
Generating a graceful crash report (your trace) is as easy as using the crash script examples given with the download archive so we need a bit more information to start answering your question.

xmpp4r throws exception on login: "Exception caught in Parser thread! (Jabber::ServerDisconnected)"

I tried to connect to my XMPP server using xmpp4r in ruby and my code is very simple, but I don't know why I got error.
I can successfully use ichat to log in using chat#localhost and also to the 5280/admin website.
require 'xmpp4r/client'
include Jabber
Jabber::debug = true
jid = Jabber::JID.new('chat#localhost')
client = Jabber::Client.new(jid)
client.connect
client.auth('123456')
client.close
And the error is:
D, [2013-02-18T03:24:55.768029 #15238] DEBUG -- : Debugging mode enabled.
W, [2013-02-18T03:24:55.768341 #15238] WARN -- : Warnings mode enabled.
D, [2013-02-18T03:24:55.772467 #15238] DEBUG -- : RESOLVING:
_xmpp-client._tcp.localhost (SRV)
D, [2013-02-18T03:24:55.778631 #15238] DEBUG -- : CONNECTING:
localhost:5222
D, [2013-02-18T03:24:55.780122 #15238] DEBUG -- : SENDING:
<stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client' to='localhost' xml:lang='en' version='1.0' >
D, [2013-02-18T03:24:55.782276 #15238] DEBUG -- : RECEIVED:
<stream:stream from='localhost' id='3021975152' xml:lang='en'
xmlns:stream='http://etherx.jabber.org/streams' version='1.0'
xmlns='jabber:client'/>
D, [2013-02-18T03:24:55.784022 #15238] DEBUG -- : RECEIVED:
<stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism></mechanisms><c hash='sha-1'
node='http://www.process-one.net/en/ejabberd/'
ver='yy7di5kE0syuCXOQTXNBTclpNTo=' xmlns='http://jabber.org/protocol/caps'/>
<register xmlns='http://jabber.org/features/iq-register'/></stream:features>
D, [2013-02-18T03:24:55.784203 #15238] DEBUG -- : FEATURES: waiting...
D, [2013-02-18T03:24:55.784785 #15238] DEBUG -- : FEATURES: received
D, [2013-02-18T03:24:55.785290 #15238] DEBUG -- : PROCESSING:
<stream:features xmlns='jabber:client'><mechanisms
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1</mechanism>
<mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><c
hash='sha-1' node='http://www.process-one.net/en/ejabberd/'
ver='yy7di5kE0syuCXOQTXNBTclpNTo=' xmlns='http://jabber.org/protocol/caps'/>
<register xmlns='http://jabber.org/features/iq-register'/></stream:features>
(REXML::Element)
D, [2013-02-18T03:24:55.785360 #15238] DEBUG -- : FEATURES: waiting finished
D, [2013-02-18T03:24:55.785450 #15238] DEBUG -- : TRYING stanzacbs...
D, [2013-02-18T03:24:55.785556 #15238] DEBUG -- : TRYING
message/iq/presence/cbs...
D, [2013-02-18T03:24:55.785987 #15238] DEBUG -- : SENDING:
<auth mechanism='DIGEST-MD5' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
D, [2013-02-18T03:24:55.787784 #15238] DEBUG -- : RECEIVED:
<challenge xmlns='urn:ietf:params:xml:ns:xmppsasl'>bm9uY2U9IjE5NzEzNzk5NzQiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=</challenge>
D, [2013-02-18T03:24:55.788143 #15238] DEBUG -- : SASL DIGEST-MD5 challenge:
nonce="1971379974",qop="auth",charset=utf-8,algorithm=md5-sess
{"nonce"=>"1971379974", "qop"=>"auth", "charset"=>"utf-8", "algorithm"=>"md5-sess"}
D, [2013-02-18T03:24:55.788475 #15238] DEBUG -- : SASL DIGEST-MD5 response:
nonce="1971379974",charset=utf-8,username="chat",realm="localhost",cnonce="92a37c018b9c32339c4b52ee0b02d67e",nc=00000001,qop=auth,digest-uri="xmpp/localhost",response=9c6bca9f4cf6f8daf3197a914023729a
{"nonce"=>"\"1971379974\"", "charset"=>"utf-8", "username"=>"\"chat\"", "realm"=>"\"localhost\"", "cnonce"=>"\"92a37c018b9c32339c4b52ee0b02d67e\"", "nc"=>"00000001", "qop"=>"auth", "digest-uri"=>"\"xmpp/localhost\"", "response"=>"9c6bca9f4cf6f8daf3197a914023729a"}
D, [2013-02-18T03:24:55.788761 #15238] DEBUG -- : SENDING:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bm9uY2U9IjE5NzEzNzk5NzQiLGNoYXJzZXQ9dXRmLTgsdXNlcm5hbWU9ImNoYXQiLHJlYWxtPSJsb2NhbGhvc3QiLGNub25jZT0iOTJhMzdjMDE4YjljMzIzMzljNGI1MmVlMGIwMmQ2N2UiLG5jPTAwMDAwMD
AxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvbG9jYWxob3N0IixyZXNwb25zZT05YzZiY2E5ZjRjZjZm
OGRhZjMxOTdhOTE0MDIzNzI5YQ==</response>
D, [2013-02-18T03:24:55.818548 #15238] DEBUG -- : RECEIVED:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-
sasl'>cnNwYXV0aD01NTQ2NTVlYjljYWUzZGExMjhmZjBkMWUzNDUzYmIwZQ==</challenge>
D, [2013-02-18T03:24:55.819064 #15238] DEBUG -- : SENDING:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
D, [2013-02-18T03:24:56.147820 #15238] DEBUG -- : RECEIVED:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
D, [2013-02-18T03:24:56.148432 #15238] DEBUG -- : SENDING:
<stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client' to='localhost' xml:lang='en' version='1.0' >
D, [2013-02-18T03:25:56.151018 #15238] DEBUG -- : SENDING:
W, [2013-02-18T03:25:56.212617 #15238] WARN -- : EXCEPTION:
Jabber::ServerDisconnected
Server Disconnected!
/home/ubuntu/.rvm/gems/ruby-1.9.3-p385/gems/xmpp4r-
0.5/lib/xmpp4r/streamparser.rb:68:in `block in parse'
/home/ubuntu/.rvm/rubies/ruby-1.9.3-
p385/lib/ruby/1.9.1/rexml/parsers/sax2parser.rb:195:in `call'
/home/ubuntu/.rvm/rubies/ruby-1.9.3-
p385/lib/ruby/1.9.1/rexml/parsers/sax2parser.rb:195:in `block in handle'
/home/ubuntu/.rvm/rubies/ruby-1.9.3-
p385/lib/ruby/1.9.1/rexml/parsers/sax2parser.rb:195:in `each'
/home/ubuntu/.rvm/rubies/ruby-1.9.3-
p385/lib/ruby/1.9.1/rexml/parsers/sax2parser.rb:195:in `handle'
/home/ubuntu/.rvm/rubies/ruby-1.9.3-
p385/lib/ruby/1.9.1/rexml/parsers/sax2parser.rb:95:in `parse'
/home/ubuntu/.rvm/gems/ruby-1.9.3-p385/gems/xmpp4r-
0.5/lib/xmpp4r/streamparser.rb:79:in `parse'
/home/ubuntu/.rvm/gems/ruby-1.9.3-p385/gems/xmpp4r-
0.5/lib/xmpp4r/stream.rb:75:in `block in start'
W, [2013-02-18T03:25:56.212740 #15238] WARN -- : Exception caught in Parser
thread! (Jabber::ServerDisconnected)
/home/ubuntu/.rvm/gems/ruby-1.9.3-p385/gems/xmpp4r-
0.5/lib/xmpp4r/streamparser.rb:68:in `block in parse'
Any ideas?
Thanks!!
I also faced this issue when sending message over facebook using Jabber.
Even wrapped in a try/catch, sometimes, Jabber::ServerDisconnected thrown and caused web server stop.
In xmpp4r source code, they thrown Jabber::ServerDisconnected when received disconnected signal and Thread.abort_on_exception = true in each thread
Ref https://github.com/lnussbaum/xmpp4r/blob/master/lib/xmpp4r/streamparser.rb and https://github.com/lnussbaum/xmpp4r/blob/master/lib/xmpp4r/stream.rb
I guess exception thrown in an orphan thread.
I have no solution, but a workaround that set Thread::abort_on_exception = false globally (in class/method using Jabber). So exception still thrown, but we ignore it.
There is a better way of handling errors, as mentioned in the docs:
If you want your connection to survive disconnects and timeouts, catch exception in Stream#on_exception and re-call Client#connect and Client#auth. Don‘t forget to re-send initial Presence and everything else you need to setup your session.
Stream#on_exception link

Resources