NAME

Net::STOMP::Client::Frame - Frame support for Net::STOMP::Client

SYNOPSIS

use Net::STOMP::Client::Frame;

# create a connection frame
$frame = Net::STOMP::Client::Frame->new(
    command => "CONNECT",
    headers => {
        login    => "guest",
        passcode => "guest",
    },
);

# get the command
$cmd = $frame->command();

# set the body
$frame->body("...some data...");

# directly get a header field
$msgid = $frame->header("message-id");

DESCRIPTION

This module provides an object oriented interface to manipulate STOMP frames.

A frame object has the following attributes: command, headers and body. The headers must be a reference to a hash of header key/value pairs.

FUNCTIONS

This module provides the following methods:

check()

check that the frame is well-formed, see below for more information

header(NAME)

return the value associated with the given name in the header

debug([TAG])

if debugging is enabled, dump a frame object on STDERR; for the body, at most $Net::STOMP::Client::Frame::DebugBodyLength bytes will be printed

CONTENT LENGTH

The "content-length" header is special because it is used to indicate the length of the body but also the JMS type of the message in ActiveMQ as per http://activemq.apache.org/stomp.html.

If you do not supply a "content-length" header, following the protocol recommendations, a "content-length" header will be added if the frame has a body.

If you do supply a numerical "content-length" header, it will be used as is. Warning: this may give unexpected results if the supplied value does not match the body length. Use only with caution!

Finally, if you supply an empty string as the "content-length" header, it will not be sent, even if the frame has a body. This can be used to mark a message as being a TextMessage for ActiveMQ. Here is an example of this:

$stomp->send(
    "destination"    => "/queue/test",
    "body"           => "hello world!",
    "content-length" => "",
);

ENCODING

The STOMP 1.0 specification does not define which encoding should be used to serialize frames. So, by default, this module assumes that what has been given by the user or by the server is a ready-to-use sequence of bytes and it does not perform any further encoding or decoding.

However, for convenience, three global variables can be used to control encoding/decoding.

If $Net::STOMP::Client::Frame::UTF8Header is set to true, the module will use UTF-8 to encode/decode the header part of the frame.

The STOMP 1.1 specification states that UTF-8 encoding should always be used for the header. So, for STOMP 1.1 connections, $Net::STOMP::Client::Frame::UTF8Header defaults to true.

If $Net::STOMP::Client::Frame::BodyEncode is set to true, the module will use the content-type header to decide when and how to encode/decode the body part of the frame.

The STOMP 1.1 specification states that the content-type header defines when and how the body is encoded/decoded. So, for STOMP 1.1 connections, $Net::STOMP::Client::Frame::BodyEncode defaults to true. As a consequence, if you use STOMP 1.1 and supply an already encoded body, you should set $Net::STOMP::Client::Frame::BodyEncode to false to prevent double encoding.

If $Net::STOMP::Client::Frame::StrictEncode is true, all encoding/decoding operations will be stricter and will report a fatal error when given malformed input. This is done by using the Encode::FB_CROAK flag instead of the default Encode::FB_DEFAULT.

N.B.: Perl's standard Encode module is used for all encoding/decoding operations.

COMPLIANCE

STOMP 1.0 has several ambiguities and this module does its best to work "as expected" in these gray areas.

STOMP 1.1 is much better specified and this module should be fully compliant with the STOMP 1.1 specification with two exceptions:

invalid encoding

by default, this module is permissive and allows malformed encoded data (this is the same default as the Encode module itself); to be strict, set $Net::STOMP::Client::Frame::StrictEncode to true (as explained above)

header keys

by default, this module allows only "reasonable" header keys, made of alphanumerical characters (along with _, - and .); to be able to use any header key (like the specification allows), set $Net::STOMP::Client::Frame::HeaderNameRE to q/[\d\D]+/.

So, to sum up, here is what you can add to your code to get strict STOMP 1.1 compliance:

$Net::STOMP::Client::Frame::StrictEncode = 1;
$Net::STOMP::Client::Frame::HeaderNameRE = q/[\d\D]+/;

FRAME CHECKING

Net::STOMP::Client calls the check() method for every frame about to be sent and for every received frame.

The check() method verifies that the frame is well-formed. For instance, it must contain a command made of uppercase letters.

The global variable $Net::STOMP::Client::Frame::CheckLevel controls the amount of checking that is performed. The default value is 2.

0

nothing is checked

1
  • the frame must have a good looking command

  • the header keys must be good looking and their value must be defined

2
  • the level 1 checks are performed

  • the frame must have a known command

  • the presence/absence of the body is checked; for instance, body is not expected for a "CONNECT" frame

  • the presence of mandatory keys (e.g. "message-id" for a "MESSAGE" frame) is checked

  • for known header keys, their value must be good looking (e.g. the "timestamp" value must be an integer)

3
  • the level 2 checks are performed

  • all header keys must be known/expected

A violation of any of these checks trigger an error in the check() method.

SEE ALSO

Net::STOMP::Client::Debug, Encode.

AUTHOR

Lionel Cons http://cern.ch/lionel.cons

Copyright CERN 2010-2011

3 POD Errors

The following errors were encountered while parsing the POD:

Around line 649:

Expected text after =item, not a number

Around line 663:

Expected text after =item, not a number

Around line 692:

Expected text after =item, not a number