Apex Code Development You need to sign in to do that
Don't have an account?
DougFriedman Issue with Streaming API from Ruby/Node
Please see the following thread from the Faye google group. (http://faye.jcoglan.com for more info on Faye). Any suggestions on how to debug a 500 Server Error when connecting with a server-side Bayeux client and OAuth token? If the issue was authentication, or a bad request, shouldn't we be getting a 400 error?
https://groups.google.com/forum/?fromgroups#!topic/faye-users/SaEiojGQx3w
Thanks
Doug
I was actually able to get this to work, though the fix did not seem to be cookie related as far as I can tell. I will say that the error codes coming back from Salesforce's servers can be quite misleading. Thanks for your help.
All Answers
Is there a way to test something like this via a CURL command? Lets say I have gone through the handshake and I have a client_id. Is there a command I can run that would prove one way or another whether it is possible to connect to a PushTopic?
posted reply back to the group
Since I'm using the exact same version of Faye that I was using earlier, I'm going to assume something changed on the part of Salesforce's Streaming API, so I'll respond here:
Seems like this may be an authentication issue. The remaining quetison is: can anyone sucessfully connect to the Salesforce Streaming API via an OAuth token?
An update to anyone (Beuller?) interested . I am able to connect to the streaming API via an OAuth Token by obtaining one externally and hard coding the sessionid variable in the example provided in the docs.
The issue is that you are not returning the "BAYEUX_BROWSER" cookie that was sent back to you when you performed the client handshake. We require that all clients follow standard cookie protocol in that all cookies that are applicable for the domain and URL are sent with the request. In this particular case, we have a bug which unfortunately causes this cookie check to fail with a null pointer exception, resulting in an 500 response. This has been fixed and will be pushed out in the next patch release.
Again, it is critical that any client collect the cookies returned by streaming API requests and send the appropriate cookies back with subsequent requests.
We apologize for the obscure 500 response due to this bug. The patch I put in for this will return a much more descriptive and appropriate response for this condition so that it will be far easier to debug.
I was actually able to get this to work, though the fix did not seem to be cookie related as far as I can tell. I will say that the error codes coming back from Salesforce's servers can be quite misleading. Thanks for your help.
I apologize for the misleading error codes. Can you tell me more about what you believe fixed the problem? Also, too, what error codes you found misleading? I understand the 500 error is completely opaque in this case, but did you run in to other issues which also resulted in misleading return codes?
Also, if it's possible, can you take a trace of your failing case using a logging proxy so I can figure out what exactly was going on? I've found the single most valuable tool in debuggin code for the Streaming API is a logging proxy such as BURP (http://portswigger.net/burp/proxy.html). There are others out there, of course, but the valuable thing these do is provide a log of exactly what is sent over the wire.
If it's possible to do, it would be invaluable to us if you could provide a trace of a session which failed (from login to end) of all the request/response traffic. With such we can work to fix the misleading responses so that no one has to suffer these again ;)
Thanks.
Sure. I'm going to follow up offline on this one though.