draft-ietf-hybi-permessage-compression-07.txt   draft-ietf-hybi-permessage-compression-08.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track March 19, 2013 Intended status: Standards Track April 1, 2013
Expires: September 20, 2013 Expires: October 3, 2013
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-07 draft-ietf-hybi-permessage-compression-08
Abstract Abstract
This document specifies a framework for creating WebSocket extensions This document specifies a framework for creating WebSocket extensions
that add compression functionality to the WebSocket Protocol. An that add compression functionality to the WebSocket Protocol. An
extension based on this framework compresses the payload data portion extension based on this framework compresses the payload data portion
of non-control WebSocket messages on per-message basis using of non-control WebSocket messages on per-message basis using
parameters negotiated during the opening handshake. This framework parameters negotiated during the opening handshake. This framework
provides a general method to apply a compression algorithm to the provides a general method to apply a compression algorithm to the
contents of WebSocket messages. For each compression algorithm, an contents of WebSocket messages. For each compression algorithm, an
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current. Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 20, 2013. This Internet-Draft will expire on October 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance Requirements and Terminology . . . . . . . . . . . 4 2. Conformance Requirements and Terminology . . . . . . . . . . . 4
3. WebSocket Per-message Compression Extension . . . . . . . . . 5 3. WebSocket Per-message Compression Extension . . . . . . . . . 5
4. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6 4. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6
4.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 7 4.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . 7
5. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 9
6. permessage-deflate extension . . . . . . . . . . . . . . . . . 10 6. permessage-deflate extension . . . . . . . . . . . . . . . . . 10
6.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 11 6.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Context Takeover Control . . . . . . . . . . . . . . . 11 6.1.1. Context Takeover Control . . . . . . . . . . . . . . . 11
6.1.2. Limiting the LZ77 sliding window size . . . . . . . . 11 6.1.2. Limiting the LZ77 sliding window size . . . . . . . . 11
6.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Payload Data Transformation . . . . . . . . . . . . . . . 13 6.2. Payload Data Transformation . . . . . . . . . . . . . . . 13
6.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 14 6.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 14
6.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 6, line 25 skipping to change at page 6, line 25
"Sec-WebSocket-Extensions" header, one for each PMCE offered. The "Sec-WebSocket-Extensions" header, one for each PMCE offered. The
set of elements MAY include multiple PMCEs with the same extension set of elements MAY include multiple PMCEs with the same extension
name to offer use of the same algorithm with different configuration name to offer use of the same algorithm with different configuration
parameters. parameters.
To accept use of an offered PMCE, a server includes a To accept use of an offered PMCE, a server includes a
"Sec-WebSocket-Extensions" header element with the extension name of "Sec-WebSocket-Extensions" header element with the extension name of
the PMCE in the "Sec-WebSocket-Extensions" header in the server's the PMCE in the "Sec-WebSocket-Extensions" header in the server's
opening handshake of the WebSocket connection. Extension parameters opening handshake of the WebSocket connection. Extension parameters
in the element represent the configuration parameters of the PMCE to in the element represent the configuration parameters of the PMCE to
use in detail. The element MUST represent a PMCE that is fully use in detail. We call these extension parameters and their values
supported by the server. "agreed parameters". The element MUST represent a PMCE that is fully
supported by the server. The contents of the element doesn't need to
exactly the same as one of the received offers. For example, an
offer with an extension parameter "X" indicating availability of the
feature X may be accepted with an element without the extension
parameter meaning that the server declined use of the feature.
A server MUST NOT accept a PMCE offer together with any extension if A server MUST NOT accept a PMCE offer together with any extension if
the PMCE will conflict with the extension on use of the RSV1 bit. A the PMCE will conflict with the extension on use of the RSV1 bit. A
client received a response accepting a PMCE offer together with such client received a response accepting a PMCE offer together with such
an extension MUST _Fail the WebSocket Connection_. an extension MUST _Fail the WebSocket Connection_.
A server MUST NOT accept a PMCE offer together with any extension if A server MUST NOT accept a PMCE offer together with any extension if
the PMCE will be applied to output of the extension and any of the the PMCE will be applied to output of the extension and any of the
following conditions is met about the extension: following conditions is met about the extension:
skipping to change at page 8, line 7 skipping to change at page 8, line 7
permessage-foo, permessage-bar permessage-foo, permessage-bar
o Offer the permessage-foo with a parameter use_y which enables a o Offer the permessage-foo with a parameter use_y which enables a
feature y as first choice, and the permessage-foo without the feature y as first choice, and the permessage-foo without the
use_y parameter as a fallback plan. use_y parameter as a fallback plan.
permessage-foo; use_y, permessage-foo permessage-foo; use_y, permessage-foo
5. Framing 5. Framing
PMCEs operate only on non-control messages. PMCEs operate only on non-control messages. PMCEs operate only on
the payload data portion and the "Per-message Compressed" bit.
This document allocates the RSV1 bit of the WebSocket header for This document allocates the RSV1 bit of the WebSocket header for
PMCEs, and calls the bit the "Per-message Compressed" bit. On a PMCEs, and calls the bit the "Per-message Compressed" bit. On a
WebSocket connection where a PMCE is in use, this bit indicates WebSocket connection where a PMCE is in use, this bit indicates
whether a message is compressed or not. whether a message is compressed or not.
A message with the "Per-message Compressed" bit set on the first A message with the "Per-message Compressed" bit set on the first
fragment of the message is called "compressed message". Frames of a fragment of the message is called "compressed message". Frames of a
compressed message have compressed data in the payload data portion. compressed message have compressed data in the payload data portion.
An endpoint received a compressed message decompresses the An endpoint received a compressed message decompresses the
skipping to change at page 8, line 32 skipping to change at page 8, line 33
Been Received_ event instead of the received data as-is. Been Received_ event instead of the received data as-is.
A message with the "Per-message Compressed" bit unset on the first A message with the "Per-message Compressed" bit unset on the first
fragment of the message is called "uncompressed message". Frames of fragment of the message is called "uncompressed message". Frames of
an uncompressed message have uncompressed original data as-is in the an uncompressed message have uncompressed original data as-is in the
payload data portion. An endpoint received an uncompressed message payload data portion. An endpoint received an uncompressed message
uses the concatenation of the application data portion of the frames uses the concatenation of the application data portion of the frames
of the message as-is for the _A WebSocket Message Has Been Received_ of the message as-is for the _A WebSocket Message Has Been Received_
event. event.
5.1. Sending 5.1. Compression
To send a message in the form of a compressed message, an endpoint An endpoint MUST use the following algorithm to send a message in the
uses the following algorithm. form of a compressed message.
1. Compress the payload data portion of the original message by 1. Compress the payload data portion of the original message by
following the compression procedure of the PMCE. following the compression procedure of the PMCE. The original
message may input from application layer or output of another
2. Build frame(s) by putting the compressed data instead of the WebSocket extension depending on what extensions are negotiated.
original data for the payload data portion.
3. Set the "Per-message Compressed" bit of the first frame.
4. Send the frame(s).
To send a message in the form of an uncompressed message, an endpoint
uses the following algorithm.
1. Build frame(s) by putting the original data for payload data
portion as-is.
2. Unset the "Per-message Compressed" bit of the first frame. 2. If this PMCE is the last extension to process outgoing messages,
build frame(s) by putting the compressed data instead of the
original data for the payload data portion, set the "Per-message
Compressed" bit of the first frame, and send the frame(s).
Otherwise, pass the transformed payload data and modified header
values including "Per-message Compressed" bit value set to 1 to
the next extension.
3. Send the frame(s). An endpoint MUST use the following algorithm to send a message in the
form of an uncompressed message. If this PMCE is the last extension
to process outgoing messages, build frame(s) by putting the original
data for payload data portion as-is, unset the "Per-message
Compressed" bit of the first frame, and send the frame(s).
Otherwise, pass the payload data and header values to the next
extension as-is.
An endpoint MUST NOT set the "Per-message Compressed" bit of control An endpoint MUST NOT set the "Per-message Compressed" bit of control
frames and non-first fragments of a data message. An endpoint frames and non-first fragments of a data message. An endpoint
received such a frame MUST _Fail the WebSocket Connection_. received such a frame MUST _Fail the WebSocket Connection_.
PMCEs don't change the opcode field. The opcode of the first frame PMCEs don't change the opcode field. The opcode of the first frame
of a compress message indicates the opcode of the original message. of a compress message indicates the opcode of the original message.
The payload data portion in frames generated by a PMCE is not subject The payload data portion in frames generated by a PMCE is not subject
to the constraints for the original data type. For example, the to the constraints for the original data type. For example, the
concatenation of the data corresponding to the application data concatenation of the data corresponding to the application data
portion of frames of a compressed text message may be not valid portion of frames of a compressed text message may be not valid
UTF-8. At the receiver, the payload data portion after decompression UTF-8. At the receiver, the payload data portion after decompression
is subject to the constraints for the original data type again. is subject to the constraints for the original data type again.
5.2. Receiving 5.2. Decompression
To receive a message in the form of a compressed message, an endpoint An endpoint MUST use the following algorithm to receive a message in
uses the following algorithm. the form of a compressed message.
1. Concatenate the payload data portion of the received frames of 1. Concatenate the payload data portion of the received frames of
the compressed message. the compressed message. The received frames may direct input
from underlying transport or output of another WebSocket
extension depending on what extensions are negotiated.
2. Decompress the concatenation by following the decompression 2. Decompress the concatenation by following the decompression
procedure of the PMCE. procedure of the PMCE.
To receive a message in the form of an uncompressed message, an 3. If this is the last extension to process incoming messages,
endpoint uses the following algorithm. deliver the _A WebSocket Message Has Been Received_ event to the
application layer with the decompressed payload data and header
1. Concatenate the payload data portion of the received frames of values including the "Per-message Compressed" bit unset to 0.
the uncompressed message. Otherwise, pass the decompressed payload data and header values
including the "Per-message Compressed" bit unset to 0 to the next
extension.
2. Handle the concatenation as-is. An endpoint MUST use the following algorithm to receive a message in
the form of an uncompressed message. If this PMCE is the last
extension to process incoming messages, deliver the _A WebSocket
Message Has Been Received_ event to the application layer with the
received payload data and header values as-is. Otherwise, pass the
payload data and header values to the next extension as-is.
6. permessage-deflate extension 6. permessage-deflate extension
This section specifies a specific PMCE called "permessage-deflate". This section specifies a specific PMCE called "permessage-deflate".
It compresses the payload data portion of messages using the DEFLATE It compresses the payload data portion of messages using the DEFLATE
[RFC1951] and the byte boundary aligning method introduced in [RFC1951] and the byte boundary aligning method introduced in
[RFC1979]. [RFC1979].
The registered extension name for this extension is The registered extension name for this extension is
"permessage-deflate". "permessage-deflate".
skipping to change at page 11, line 18 skipping to change at page 11, line 18
o The client doesn't support the configuration the response o The client doesn't support the configuration the response
represents. represents.
6.1. Method Parameters 6.1. Method Parameters
6.1.1. Context Takeover Control 6.1.1. Context Takeover Control
A client MAY attach the "s2c_no_context_takeover" extension A client MAY attach the "s2c_no_context_takeover" extension
parameter. The "s2c_no_context_takeover" extension parameter has no parameter. The "s2c_no_context_takeover" extension parameter has no
value. If a server received the "s2c_no_context_takeover" extension value. Using this extension parameter, a client can disallow the
parameter, the server MUST NOT use the same LZ77 sliding window to peer server to use the same LZ77 sliding window to build frames of
compress two or more messages. Servers SHOULD be able to accept the the last sent message to build frames of the next message to send.
"s2c_no_context_takeover" parameter. A server accepts an offer with If the peer server doesn't use the same LZ77 sliding window to
this extension parameter by including the "s2c_no_context_takeover" compress two or more messages, the client can reduce the amount of
extension parameter in the response. If a server accepted an offer memory for the LZ77 sliding window to decompress received messages.
with this extension parameter, the server MUST empty its LZ77 sliding A server accepts an offer with this extension parameter by including
window to compress messages to send each time the server builds a new the "s2c_no_context_takeover" extension parameter in the response. A
server accepted an offer with this extension parameter MUST empty its
LZ77 sliding window to compress messages to send each time the server
builds a new message.
It is RECOMMENDED to make a server be able to accept the
"s2c_no_context_takeover" parameter.
A server MAY attach the "c2s_no_context_takeover" extension
parameter. The "c2s_no_context_takeover" extension parameter has no
value. Using this extension parameter, a server can disallow the
peer client to use the LZ77 sliding window used to build frames of
the last sent message to build frames for the next message to send.
If the peer client doesn't use the same LZ77 sliding window to
compress two or more messages, the server can reduce the amount of
memory for the LZ77 sliding window to decompress received messages.
A client that received this parameter MUST empty its LZ77 sliding
window to compress messages to send each time the client builds a new
message. message.
A server MAY attach the "c2s_no_context_takeover" extension parameter It is RECOMMENDED to make a client be able to accept the
to disallow the client to use the LZ77 sliding window used to build "c2s_no_context_takeover" parameter.
frames for the last message the client sent to build frames for the
next message to send. The "c2s_no_context_takeover" extension
parameter has no value. Clients SHOULD be able to accept the
"c2s_no_context_takeover" parameter. A client that received this
parameter MUST reset its LZ77 sliding window for sending to empty for
each message.
6.1.2. Limiting the LZ77 sliding window size 6.1.2. Limiting the LZ77 sliding window size
A client MAY attach the "s2c_max_window_bits" extension parameter to A client MAY attach the "s2c_max_window_bits" extension parameter to
limit the LZ77 sliding window size that the server uses to build limit the LZ77 sliding window size that the server uses to build
messages. This extension parameter MUST have a decimal integer value messages. This extension parameter MUST have a decimal integer value
in the range between 8 to 15 indicating the base-2 logarithm of the in the range between 8 to 15 indicating the base-2 logarithm of the
LZ77 sliding window size. LZ77 sliding window size.
s2c_max_window_bits = 1*DIGIT s2c_max_window_bits = 1*DIGIT
skipping to change at page 14, line 16 skipping to change at page 14, line 25
to 0 and DEFLATE blocks with the "BFINAL" bit set to 1. to 0 and DEFLATE blocks with the "BFINAL" bit set to 1.
o When any DEFLATE block with the "BFINAL" bit set to 1 doesn't end o When any DEFLATE block with the "BFINAL" bit set to 1 doesn't end
at byte boundary, an endpoint adds minimal padding bits of 0 to at byte boundary, an endpoint adds minimal padding bits of 0 to
make it end at byte boundary. The next DEFLATE block follows the make it end at byte boundary. The next DEFLATE block follows the
padded data if any. padded data if any.
An endpoint MUST NOT use an LZ77 sliding window longer than 32,768 An endpoint MUST NOT use an LZ77 sliding window longer than 32,768
bytes to compress messages to send. bytes to compress messages to send.
If a server accepts an offer with the "c2s_no_context_takeover" If the "agreed parameters" contain the "c2s_no_context_takeover"
extension parameter, the client MUST empty its LZ77 sliding window to extension parameter, the client MUST empty its LZ77 sliding window to
compress messages to send each time the client compresses a new compress messages to send each time the client compresses a new
message to send. Otherwise, the client MAY take over the LZ77 message to send. Otherwise, the client MAY take over the LZ77
sliding window used to build the last compressed message. sliding window used to build the last compressed message.
If a server accepts an offer with the "s2c_no_context_takeover" If the "agreed parameters" contain the "s2c_no_context_takeover"
extension parameter, the server MUST empty its LZ77 sliding window to extension parameter, the server MUST empty its LZ77 sliding window to
compress messages to send each time the server compresses a new compress messages to send each time the server compresses a new
message to send. Otherwise, the server MAY take over the LZ77 message to send. Otherwise, the server MAY take over the LZ77
sliding window used to build the last compressed message. sliding window used to build the last compressed message.
If a server accepts an offer with the "c2s_max_window_bits" extension If the "agreed parameters" contain the "c2s_max_window_bits"
parameter with a value of w, the client MUST NOT use an LZ77 sliding extension parameter with a value of w, the client MUST NOT use an
window longer than w-th power of 2 bytes to compress messages to LZ77 sliding window longer than w-th power of 2 bytes to compress
send. messages to send.
If a server accepts an offer with the "s2c_max_window_bits" extension If the "agreed parameters" contain the "s2c_max_window_bits"
parameter with a value of w, the server MUST NOT use an LZ77 sliding extension parameter with a value of w, the server MUST NOT use an
window longer than w-th power of 2 bytes to compress messages to LZ77 sliding window longer than w-th power of 2 bytes to compress
send. messages to send.
6.2.2. Decompression 6.2.2. Decompression
An endpoint uses the following algorithm to decompress a message. An endpoint uses the following algorithm to decompress a message.
1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail end of the 1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail end of the
payload data portion of the message. payload data portion of the message.
2. Decompress the resulting data using the DEFLATE. 2. Decompress the resulting data using the DEFLATE.
If a server accepts an offer with the "s2c_no_context_takeover" If the "agreed parameters" contain the "s2c_no_context_takeover"
extension parameter, the client MAY empty its LZ77 sliding window to extension parameter, the client MAY empty its LZ77 sliding window to
decompress received messages each time the client decompresses a new decompress received messages each time the client decompresses a new
received message. Otherwise, the client MUST take over the LZ77 received message. Otherwise, the client MUST take over the LZ77
sliding window used to process the last compressed message. sliding window used to process the last compressed message.
If a server accepts an offer with the "c2s_no_context_takeover" If the "agreed parameters" contain the "c2s_no_context_takeover"
extension parameter, the server MAY empty its LZ77 sliding window to extension parameter, the server MAY empty its LZ77 sliding window to
decompress received messages each time the server decompresses a new decompress received messages each time the server decompresses a new
received message. Otherwise, the server MUST take over the LZ77 received message. Otherwise, the server MUST take over the LZ77
sliding window used to process the last compressed message. sliding window used to process the last compressed message.
If a server accepts an offer with the "s2c_max_window_bits" extension If the "agreed parameters" contain the "s2c_max_window_bits"
parameter with a value of w, the client MAY reduce the size of its extension parameter with a value of w, the client MAY reduce the size
LZ77 sliding window to decompress received messages down to the w-th of its LZ77 sliding window to decompress received messages down to
power of 2 bytes. Otherwise, the client MUST use a 32,768 byte LZ77 the w-th power of 2 bytes. Otherwise, the client MUST use a 32,768
sliding window to decompress received messages. byte LZ77 sliding window to decompress received messages.
If a server accepts an offer with the "c2s_max_window_bits" extension If the "agreed parameters" contain the "c2s_max_window_bits"
parameter with a value of w, the server MAY reduce the size of its extension parameter with a value of w, the server MAY reduce the size
LZ77 sliding window to decompress received messages down to the w-th of its LZ77 sliding window to decompress received messages down to
power of 2 bytes. Otherwise, the server MUST use a 32,768 byte LZ77 the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768
sliding window to decompress received messages. byte LZ77 sliding window to decompress received messages.
6.2.3. Examples 6.2.3. Examples
This section introduces examples of how the permessage-deflate This section introduces examples of how the permessage-deflate
transforms messages. transforms messages.
6.2.3.1. A message compressed using 1 compressed DEFLATE block 6.2.3.1. A message compressed using 1 compressed DEFLATE block
Suppose that an endpoint sends a text message "Hello". If the Suppose that an endpoint sends a text message "Hello". If the
endpoint uses 1 compressed DEFLATE block (compressed with fixed endpoint uses 1 compressed DEFLATE block (compressed with fixed
skipping to change at page 16, line 38 skipping to change at page 16, line 49
and the second frame is: and the second frame is:
0x80 0x04 0xc9 0xc9 0x07 0x00 0x80 0x04 0xc9 0xc9 0x07 0x00
Note that the RSV1 bit is set only on the first frame. Note that the RSV1 bit is set only on the first frame.
6.2.3.2. Sharing LZ77 Sliding Window 6.2.3.2. Sharing LZ77 Sliding Window
Suppose that a client has sent a message "Hello" as a compressed Suppose that a client has sent a message "Hello" as a compressed
message and will send the same message "Hello" again as a compressed message and will send the same message "Hello" again as a compressed
message. If the server has accepted the offer with the message.
"c2s_no_context_takeover" extension parameter, the server compresses
the payload data portion of the next message into the same bytes (if
the server uses the same "BTYPE" value and "BFINAL" value):
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
If the server hasn't accepted the offer with the This is the payload of the first message the client has sent. If the
"c2s_no_context_takeover" extension parameter, the server can "agreed parameters" contain the "c2s_no_context_takeover" extension
compress the payload data portion of the next message into shorter parameter, the client compresses the payload data portion of the next
bytes utilizing the history in the LZ77 sliding window: message into the same bytes (if the client uses the same "BTYPE"
value and "BFINAL" value). So, the payload will be:
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
If the "agreed parameters" contain the "c2s_no_context_takeover"
extension parameter, the client can compress the payload data portion
of the next message into shorter bytes utilizing the history in the
LZ77 sliding window. So, the payload will be:
0xf2 0x00 0x11 0x00 0x00 0xf2 0x00 0x11 0x00 0x00
Note that even if any uncompressed message (any message with the RSV1 Note that even if any uncompressed message (any message with the RSV1
bit unset) is inserted between the two "Hello" messages, such a bit unset) is inserted between the two "Hello" messages, such a
message doesn't make any change on the LZ77 sliding window. message doesn't make any change on the LZ77 sliding window.
6.2.3.3. Using a DEFLATE Block with No Compression 6.2.3.3. Using a DEFLATE Block with No Compression
Suppose that an endpoint compresses a text message "Hello" using a
DEFLATE block with no compression. A DEFLATE block with no
compression containing "Hello" flushed into a byte array using
another but empty DEFLATE block with no compression is:
0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
0x00 0x00 0xff 0xff
The endpoint strips the 4 octets at the tail end:
0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
The endpoint builds a frame by putting the resulting data in the
payload data portion of the frame:
0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00 0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
The first 2 octets (0xc1 0x0b) are the WebSocket frame header (FIN=1, This is a frame consisting a text message "Hello" compressed using a
RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). Note DEFLATE block with no compression. The first 2 octets (0xc1 0x0b)
that the RSV1 bit is set for this message (only on the first fragment are the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0,
if the message is fragmented) because the RSV1 bit is set when the opcode=text, MASK=0, Payload length=7). Note that the RSV1 bit is
DEFLATE is applied to the message and it includes the case only set for this message (only on the first fragment if the message is
DEFLATE blocks with no compression are used. fragmented) because the RSV1 bit is set when the DEFLATE is applied
to the message and it includes the case only DEFLATE blocks with no
compression are used. The third to 13th octet consists a payload
containing "Hello" compressed using a DEFLATE block with no
compression.
6.2.3.4. Using a DEFLATE Block with BFINAL Set to 1 6.2.3.4. Using a DEFLATE Block with BFINAL Set to 1
On platform where the flush method using an empty DEFLATE block with On platform where the flush method using an empty DEFLATE block with
no compression is not avaiable, implementors can choose to flush data no compression is not avaiable, implementors can choose to flush data
using DEFLATE blocks with "BFINAL" set to 1. Using a DEFLATE block using DEFLATE blocks with "BFINAL" set to 1.
with "BFINAL" set to 1 and "BTYPE" set to 1, "Hello" is compressed
into:
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00
So, payload of a message containing "Hello" compressed using this
method is:
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
The last 1 octet (0x00) contains the header bits with "BFINAL" set to This is a payload of a message containing "Hello" compressed using a
0 and "BTYPE" set to 0, and 7 padding bits of 0. This octet is DEFLATE block with "BFINAL" set to 1. The first 7 octet consist a
necessary to allow the payload to be decompressed in the same manner DEFLATE block with "BFINAL" set to 1 and "BTYPE" set to 1 containing
as messages flushed using DEFLATE blocks with BFINAL unset. "Hello". The last 1 octet (0x00) contains the header bits with
"BFINAL" set to 0 and "BTYPE" set to 0, and 7 padding bits of 0.
This octet is necessary to allow the payload to be decompressed in
the same manner as messages flushed using DEFLATE blocks with BFINAL
unset.
6.2.3.5. Two DEFLATE Blocks in 1 Message 6.2.3.5. Two DEFLATE Blocks in 1 Message
Two or more DEFLATE blocks may be used in 1 message. Two or more DEFLATE blocks may be used in 1 message.
0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x00 0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x00
The first 3 octets (0xf2 0x48 0x05) and the least significant two The first 3 octets (0xf2 0x48 0x05) and the least significant two
bits of the 4th octet (0x00) consist one DEFLATE block with "BFINAL" bits of the 4th octet (0x00) consist one DEFLATE block with "BFINAL"
set to 0 and "BTYPE" set to 1 containing "He";. The rest of the 4th set to 0 and "BTYPE" set to 1 containing "He";. The rest of the 4th
skipping to change at page 21, line 14 skipping to change at page 21, line 14
9. Acknowledgements 9. Acknowledgements
Special thanks to Patrick McManus who wrote up the initial Special thanks to Patrick McManus who wrote up the initial
specification of a DEFLATE-based compression extension for the specification of a DEFLATE-based compression extension for the
WebSocket Protocol to which I referred to write this specification. WebSocket Protocol to which I referred to write this specification.
Thank you to the following people who participated in discussions on Thank you to the following people who participated in discussions on
the HyBi WG and contributed ideas and/or provided detailed reviews the HyBi WG and contributed ideas and/or provided detailed reviews
(the list is likely to be incomplete): Alexey Melnikov, Arman (the list is likely to be incomplete): Alexey Melnikov, Arman
Djusupov, Bjoern Hoehrmann, Brian McKelvey, Greg Wilkins, Inaki Baz Djusupov, Bjoern Hoehrmann, Brian McKelvey, Dario Crivelli, Greg
Castillo, Jamie Lokier, Joakim Erdfelt, John A. Tamplin, Julian Wilkins, Inaki Baz Castillo, Jamie Lokier, Joakim Erdfelt, John A.
Reschke, Kenichi Ishibashi, Mark Nottingham, Peter Thorson, Roberto Tamplin, Julian Reschke, Kenichi Ishibashi, Mark Nottingham, Peter
Peon and Simone Bordet. Note that people listed above didn't Thorson, Roberto Peon and Simone Bordet. Note that people listed
necessarily endorse the end result of this work. above didn't necessarily endorse the end result of this work.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011. RFC 6455, December 2011.
 End of changes. 33 change blocks. 
122 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/