[Pidgin] #7290: IQ packet has no ID Tag: Violation of RFC 3920, Page 51

[Pidgin]

#7290: IQ packet has no ID Tag: Violation of RFC 3920, Page 51
--------------------+-------------------------------------------------------
 Reporter:  pentor  |        Owner:  deryni 
     Type:  defect  |       Status:  pending
Milestone:          |    Component:  XMPP   
  Version:  2.5.1   |   Resolution:         
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by datallah):

  * status:  new => pending


Comment:

 Replying to [comment:4 pentor]:
 > I believe you are wrong.
 > Read this, (it's a link in the noted URL).
 >
 > http://www.igniterealtime.org/community/message/179066

 I already looked at that - the information there is what prompted my
 response.


 > Please read the entry that states:
 > ================================
 > Sep 10, 2008 2:40 AM  in response to: Cameron Braid
 > Re: bug in openfire 3.6.0 - Closing connection due to error while
 processing message: <iq type='result' ...
 >
 >  have this problem with Pidgin too. It seems that there went something
 wrong with the SSL encryption. When I set the old SSL method to Not
 Available it works for our setup, with and wihtout TLS method and of
 course with Pidgin


 Right - he is saying that the pidgin client is getting disconnected, this
 is covered by my explanation above (and also if you continue reading the
 thread, you'll find the same conclusion there).


 > Trust me, we had to fix our server DUE TO THE PIDGIN CLIENT.

 To clarify, you had to fix your server due to a server bug that caused
 people using libpurple clients to be disconnected when they replied to
 invalid requests.  If there actually is a different issue than the one
 that you linked to, please include the debug log and we'd be happy to look
 into it.

 >
 > You state: "... which is why Pidgin isn't listed inthe Buggy clients"
 > This is in error, you ARE listed in the "buggy clients".

 Look again at the ticket you posted, we aren't (not that it really
 matters, but if we were, I'd request them to correct it).

 >
 > BTW: this "error" occured when PIDGIN tried to connect to the server on-
 startup.
 > There were no other clients sending Pidgin a broken "get".
 > Robust code handles exceptions.

 As I mentioned earlier, there doesn't appear to be any possibility of this
 happening unless we receive a broken request (which the server shouldn't
 allow) - if you can recreate this, please include the debug output.  I
 suspect what is happening is that there is actually a broken client
 sending a "jabber:iq:version" get as soon as we log on, which we're
 replying to.

 >
 > You are well winthin your purview to say: "we're not going to fix this
 code error".
 > You're not really correct saying: "we're doing things correctly, someone
 else should do the error handling for us."

 As I said, I don't believe that this is a bug on our end, the only other
 thing we could reasonably do is to drop the message, but that might cause
 other problems (e.g. the server hanging up on us because we don't reply to
 a stanza).

 It isn't a matter of someone else doing error handling for us - the server
 is allowing a non-standard message to get to the client and we're replying
 which then causes problems with the server.  The problem lies with the
 server (and the other client that is sending the broken message that
 initiated this).

-- 
Ticket URL: <http://developer.pidgin.im/ticket/7290#comment:5>
Pidgin <http://pidgin.im>
Pidgin