Re: Can we release proton 0.10? Can we add Py3K to that release?
Re: py3k - I think we're really close - I've rebased my local kgiusti-python3 to latest trunk, and have a few bugs to sort out but I don't think that will take too long. The one missing 'feature' I had planned for py3: modify the tox tests to automagically run under all installed versions of python. But this all should be do-able before the end of the month IMHO. - Original Message - > From: "Flavio Percoco" > To: "Rafael Schloming" > Cc: us...@qpid.apache.org, proton@qpid.apache.org > Sent: Wednesday, June 17, 2015 2:20:09 AM > Subject: Re: Can we release proton 0.10? Can we add Py3K to that release? > > On 16/06/15 23:38 -0400, Rafael Schloming wrote: > >I'd like to get the proton-j-reactor branch into 0.10 also. It should be > >ready > >soon, so if py3k can be sorted and merged in a similar timeframe we could > >target a release for the end of the month. > > This sounds awesome, I think it can be done based on the latest email > from Ken about Py3K. > > Thanks, > Flavio > > > > >--Rafael > > > >On Tue, Jun 16, 2015 at 3:32 PM, Flavio Percoco wrote: > > > >Greetings, > > > >I've been looking with great pleasure all the progress happening in > >proton lately and I was wondering whether it'd be possible to have an > >0.10 release cut soon. > > > >There are some bugfixes I'm personally interested in but also some > >important changes (specifically in the python bindings) that will make > >consuming proton easier for users (OpenStack among those). > > > >Is there a chance for the above to happen any time soon? > > > >Can I push my request a bit further and ask for the py3k code to be > >merged as well? > > > >All the above are key pieces to make proton more consumable and allow > >for services like OpenStack to fully adopt it. > > > >Thanks, > >Flavio > > > >-- > >@flaper87 > >Flavio Percoco > > > > > > -- > @flaper87 > Flavio Percoco > -- -K
Re: [GitHub] qpid-proton pull request: Proton 781 ruby reactor apis
On Mon, Jun 08, 2015 at 07:10:34PM +, mcpierce wrote: > GitHub user mcpierce opened a pull request: > > https://github.com/apache/qpid-proton/pull/36 > > Proton 781 ruby reactor apis > > The Ruby Reactor APIs plus example applications. Hi, all. If nobody objects, I'm going to merge this into trunk tomorrow (18 June) at COB EST unless anybody objects. This shouldn't have any impact on code outside of the Ruby bindings. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpju48VFZdNP.pgp Description: PGP signature
[jira] [Updated] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-914: Description: The method is returning the result code for the underlying C api rather than the actual value. (was: The method is returning the result code for the underlying C api rather than the actual API.) > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-914) SSL.peer_hostname does not return the proper value.
Darryl L. Pierce created PROTON-914: --- Summary: SSL.peer_hostname does not return the proper value. Key: PROTON-914 URL: https://issues.apache.org/jira/browse/PROTON-914 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.9.1 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce The method is returning the result code for the underlying C api rather than the actual API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-914: Attachment: 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Attachments: > 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-914: Attachment: (was: 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch) > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-914: Attachment: 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Attachments: > 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-915) Incompatible protocol header handled incorrectly
Gordon Sim created PROTON-915: - Summary: Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1, 0.9 Reporter: Gordon Sim Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: "If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590056#comment-14590056 ] Andrew Stitcher commented on PROTON-915: A reproducer script would be nice. > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.10 > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590077#comment-14590077 ] Gordon Sim commented on PROTON-915: --- E.g. 1. start wireshark 2. run ./examples/c/messenger/recv 3. run qpid-send --address foo Observe wireshark trace which shows qpid-cpp sending the 0-10 header and proton not sending one back. If use the recv example from proton 0.8 (in a slightly different path, ./examples/messenger/c/recv) a protocol-header *is* sent. You can substitute any other tcp server using proton-c for managing protocol version headers in step 2, e.g. dispatch router, examples/python/broker.py etc) > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.10 > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-916) [SASL] pn_sasl_config_name - name gets overwritten in python binding
Ken Giusti created PROTON-916: - Summary: [SASL] pn_sasl_config_name - name gets overwritten in python binding Key: PROTON-916 URL: https://issues.apache.org/jira/browse/PROTON-916 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 When setting the SASL configuration name from python, a pointer to a temporary string is passed to pn_sasl_config_name() by the python environment. When the environment no longer references that string, the memory is freed, leaving the sasl internal object referencing freed memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590247#comment-14590247 ] ASF subversion and git services commented on PROTON-914: Commit cbb6800496e88a0a4f22523c0f0f68afd3424323 in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=cbb6800 ] PROTON-914: Fix for getting the SSL peer hostname in Ruby. Previously the call was returning the result code rather than the actual hostname value. > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Attachments: > 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-914) SSL.peer_hostname does not return the proper value.
[ https://issues.apache.org/jira/browse/PROTON-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-914. - Resolution: Fixed Fix Version/s: 0.10 > SSL.peer_hostname does not return the proper value. > --- > > Key: PROTON-914 > URL: https://issues.apache.org/jira/browse/PROTON-914 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.9.1 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Fix For: 0.10 > > Attachments: > 0001-PROTON-914-Fix-for-getting-the-SSL-peer-hostname-in-.patch > > > The method is returning the result code for the underlying C api rather than > the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-917) [SASL] buffer underrun if no mechs specified by peer
Ken Giusti created PROTON-917: - Summary: [SASL] buffer underrun if no mechs specified by peer Key: PROTON-917 URL: https://issues.apache.org/jira/browse/PROTON-917 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.10 off by one array index error if the peer doesn't supply any mechs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-917) [SASL] buffer underrun if no mechs specified by peer
[ https://issues.apache.org/jira/browse/PROTON-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590325#comment-14590325 ] ASF subversion and git services commented on PROTON-917: Commit 718d8b37644ab9102364ce8e23ee47b029191556 in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=718d8b3 ] PROTON-917: avoid buffer underrun if no mechs given > [SASL] buffer underrun if no mechs specified by peer > > > Key: PROTON-917 > URL: https://issues.apache.org/jira/browse/PROTON-917 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.10 > > > off by one array index error if the peer doesn't supply any mechs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-916) [SASL] pn_sasl_config_name - name gets overwritten in python binding
[ https://issues.apache.org/jira/browse/PROTON-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590399#comment-14590399 ] ASF subversion and git services commented on PROTON-916: Commit 5b611b704441c508541b444300fbeb398ef61f80 in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5b611b7 ] PROTON-916: copy SASL config name to allow bindings to release the name > [SASL] pn_sasl_config_name - name gets overwritten in python binding > > > Key: PROTON-916 > URL: https://issues.apache.org/jira/browse/PROTON-916 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.10 > > > When setting the SASL configuration name from python, a pointer to a > temporary string is passed to pn_sasl_config_name() by the python > environment. When the environment no longer references that string, the > memory is freed, leaving the sasl internal object referencing freed memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590430#comment-14590430 ] Andrew Stitcher commented on PROTON-915: I have a fix for this now - try the attached patch. However this fails the current tests, because proton-j (and proton-c in client mode) ignore the spec and send the AMQP header followed by and open and immediate close frame. Which I don't think is allowed as the spec says "*MUST* ... and then close the socket". You could argue that the spec doesn't forbid bytes between the coirrect header and closing the socket, but I think that's a stretch. I can make the test less restrictive if that is the consensus here, but I think there may be a larger spec compliance issue. > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.10 > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-915: --- Attachment: 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch Putative fix for 0.10 > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590432#comment-14590432 ] Andrew Stitcher commented on PROTON-915: Assigned to [~rhs] for comment on spec compliance > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-915: --- Assignee: Rafael H. Schloming (was: Andrew Stitcher) > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590567#comment-14590567 ] Robbie Gemmell commented on PROTON-915: --- I'd agree that you could possibly argue whether the spec doesnt strictly forbids you sending any more bytes, but I do think it is the intention and would say we should not. If it was for example the non-SASL AMQP header that was received and 'not supported' because we were requiring a SASL layer first, then it would certainly seem incorrect to me send anything beyond the SASL header back. Incidentally, we should probably cover that case with tests too. For proton-j at least, the sending of the open and close frames could be related or even the same underlying issue as another I raised recently, PROTON-900. > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590579#comment-14590579 ] Andrew Stitcher commented on PROTON-915: [~gemmellr] I think this was a deliberate move from @rhs which is why I've asked him to comment - at least in the Proton-C code. > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590589#comment-14590589 ] Robbie Gemmell commented on PROTON-915: --- [~astitcher] Always a good idea. I was mainly just commenting to link the other JIRA in case someone who understands it cared to fix both :D > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-916) [SASL] pn_sasl_config_name - name gets overwritten in python binding
[ https://issues.apache.org/jira/browse/PROTON-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590764#comment-14590764 ] ASF subversion and git services commented on PROTON-916: Commit 638c18b33d4dd8f10692b975f522053a2ed4f980 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=638c18b ] PROTON-916: Avoid unnecessary heap allocation > [SASL] pn_sasl_config_name - name gets overwritten in python binding > > > Key: PROTON-916 > URL: https://issues.apache.org/jira/browse/PROTON-916 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.10 > > > When setting the SASL configuration name from python, a pointer to a > temporary string is passed to pn_sasl_config_name() by the python > environment. When the environment no longer references that string, the > memory is freed, leaving the sasl internal object referencing freed memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590765#comment-14590765 ] ASF subversion and git services commented on PROTON-915: Commit 3aab9a07bca507aa9160e00eb54179b3df441ebb in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3aab9a0 ] PROTON-915: Send correct AMQP header upon protocol mismatch - Split apart the transport tests into client and server tests > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590772#comment-14590772 ] Andrew Stitcher commented on PROTON-915: I've now committed the patch, with "fixes" to the tests to allow them to pass but I think the open question is still whether the Proton-J behaviour and the Proton-C client transport behaviour is correct according to the spec. [Another JIRA perhaps?] > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-915. Resolution: Fixed > Incompatible protocol header handled incorrectly > > > Key: PROTON-915 > URL: https://issues.apache.org/jira/browse/PROTON-915 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9, 0.9.1 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.10 > > Attachments: > 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch > > > The correct response is to send back a supported header[1] before closing the > socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this > commit: > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 > It means anything relying on proton-c for protocol header handling is not > compliant with the spec. > [1] section 2.2 of spec: "If the requested protocol version is not > supported, the server MUST send a protocol header with a supported protocol > version and then close the socket." -- This message was sent by Atlassian JIRA (v6.3.4#6332)