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_frame();   #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.