/ 
Net-WebSocket-0.24
River stage zero No dependents
/ Net::WebSocket::Frame::close

NAME

Net::WebSocket::Frame::close

SYNOPSIS

my $frm = Net::WebSocket::Frame::close->new(

    #Optional, can be either empty (default) or four random bytes
    mask => q<>,

    code => 'SUCCESS',      #See below

    reason => 'yeah, baby', #See below
);

$frm->get_type();           #"close"

$frm->is_control();   #1

my $mask = $frm->get_mask_bytes();

my ($code, $reason) = $frm->get_code_and_reason();

#If, for some reason, you need the raw payload:
my $payload = $frm->get_payload();

my $serialized = $frm->to_bytes();

Note that, as per RFC 6455, close messages can have any of:

  • no code, and no reason

    Returned as undef (for the code) and an empty string. This diverges from the RFC’s described behavior of returning code 1005.

  • a code, and no reason

    Returned as the code number and an empty string.

  • a code, and a reason that cannot exceed 123 bytes

The code (i.e., $code) is subject to the limitations that RFC 6445 describes. You can also, in lieu of a numeric constant, use the following string constants that derive from Microsoft’s WebSocket API:

  • SUCCESS (1000)

  • ENDPOINT_UNAVAILABLE (1001)

  • PROTOCOL_ERROR (1002)

  • INVALID_DATA_TYPE (1003)

  • INVALID_PAYLOAD (1007)

  • POLICY_VIOLATION (1008)

  • MESSAGE_TOO_BIG (1009)

  • UNSUPPORTED_EXTENSIONS (1010)

  • INTERNAL_ERROR, aka SERVER_ERROR (1011)

    This appears as SERVER_ERROR in Microsoft’s documentation; however, erratum 3227 updates the RFC to have this status encompass client errors as well.

    Net::WebSocket recognizes either string, but its parsing logic will return only INTERNAL_ERROR.

The following additional status constants derive from the official registry of status codes and are newer than either RFC 6455 or Microsoft’s API:

  • SERVICE_RESTART (1012)

  • TRY_AGAIN_LATER (1013)

  • BAD_GATEWAY (1014)

It is hoped that a future update to the WebSocket specification can include these or similar constant names.