Hi,
Messenger will simply use anonymous if you don't specify a username and
password, e.g. amqp://broker/node will result in the client forcing
ANONYMOUS. If you do specify a username and password, e.g.
amqp://user:pass@broker/node, then messenger will force PLAIN. There is no
way to disable SASL
Disabling SASL should be an option in proton to connect to simple services that
do not provide SASL or just to skip this additional step if SASL is not
requires.
The other problem was already reported from Sergey.
I receive a SASL protocol header and a SASL Init message with mechanism PLAIN
Adding my +1 for the record.
--Rafael
On Thu, Jan 2, 2014 at 2:17 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
It looks like there haven't been any major issues reported so far with 0.6
RC3, so I guess it's about time to call for a formal vote.
Source is here:
The vote carries with 3 binding +1's, 2 non-binding +1's, and no other
votes. I'll post the artifacts shortly.
--Rafael
On Thu, Jan 2, 2014 at 2:17 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
It looks like there haven't been any major issues reported so far with 0.6
RC3, so I
Am 14.01.2014 um 16:00 schrieb Rafael Schloming r...@alum.mit.edu:
The SASL header looks
to start where you see the sequence ...AMQP\x03\x01 This either means
that proton's internal buffers are getting messed up somehow, or there
actually is garbage on the wire.
Just checked with
Andreas, are you planning to fix the bug in the future version?
Thanks,
Sergejs.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/SASL-proton-c-questions-tp7602690p7602711.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Yes, very soon.
Andreas
Am 14.01.2014 um 18:34 schrieb serega sergejs.melde...@sap.com:
Andreas, are you planning to fix the bug in the future version?
Thanks,
Sergejs.
--
View this message in context:
On Thu, Jan 09, 2014 at 04:06:38PM -0500, Darryl L. Pierce wrote:
On Thu, Jan 09, 2014 at 03:19:52PM -0500, Rafael Schloming wrote:
In the case of the C API getting a PN_INPROGRESS error (-9) from recv is
expected behaviour if you're in non blocking mode. That just means that
there is
It looks like the actual issue has been identified on another thread, but
while this is here...I noticed that the mechanisms are in a different order
between the two snippets below, however the 1.0 spec indicates they are to
be ordered in decreasing level of preference which I would expect to make
