Description:
------------
While connecting to a rabbitmq 2.6.1, I'm having issues when 
using 
Stomp::ack() to acknowledge the received messages.

The messages are never acknowledged and the connection to the 
server 
drops with "Unexpected EOF while reading from socket". It 
seems the 
server is closing the client connection.

Reproduce code:
---------------
The following code will break with an "Unexpected EOF while reading from socket" after receiving a couple of messages. The rabbitmq (2.6.1) seems to be disconnecting the client. 

$broker = 'tcp://127.0.0.1:61613';
$queue  = '/queue/foo';
$msg    = 'bar';

try {
    $stomp = new Stomp($broker, 'guest', 'guest');
    $stomp->subscribe('/queue/commands');
    while(true) {
        if ($stomp->hasFrame()) {
            $frame = $stomp->readFrame();
            if ($frame !== false) {
                $stomp->ack($frame);
                var_dump($frame);
            }
        }
    }
    $stomp->disconnect();
} catch(StompException $e) {
    echo $e->getMessage();
}

The messages are sent in a transaction with another php script, by using Stomp::begin() and Stomp::commit(). No problems there.

After debugging a little, I ended up in FRAME_HEADER_FROM_HASHTABLE(h, p) in php_stomp.c.

It seems that stomp_ack() populates the headers in the ack message with the same headers that came with the original message. The conflicting header that triggers the issue seems to be "content-length". Patching FRAME_HEADER_FROM_HASHTABLE as follows seems to fix this issue (the messages are correctly flushed from the server and the client continues to be connected):

65c65,67
<                       zend_hash_add(h, string_key, strlen(string_key)+1, Z_STRVAL_PP(value), Z_STRLEN_PP(value)+1, NULL); \
---
>                       if (strcmp(string_key, "content-length") != 0) { \
>                               zend_hash_add(h, string_key, strlen(string_key)+1, Z_STRVAL_PP(value), Z_STRLEN_PP(value)+1, NULL); \
>                       } \

What I basically did is to NOT send content-length in the ack frame. I'm not sure this is the correct fix, but it seems to pinpoint the issue.


Expected result:
----------------
The messages should be acknowledged.
The client should continue to be connected to the server.
The messages should "go away" from the rabbitmq server.

Actual result:
--------------
The exception "Unexpected EOF while reading from socket" is 
thrown in stomp_recv() after a couple of (apparently) failed 
stomp_ack() calls.

The messages are kept in the rabbitmq server (the ack() calls 
are not flushing them from the server).