draft-ietf-hybi-permessage-compression-25.txt   draft-ietf-hybi-permessage-compression-26.txt 
HyBi Working Group T. Yoshino HyBi Working Group T. Yoshino
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track August 6, 2015 Intended status: Standards Track August 6, 2015
Expires: February 7, 2016 Expires: February 7, 2016
Compression Extensions for WebSocket Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-25 draft-ietf-hybi-permessage-compression-26
Abstract Abstract
This document defines a framework for creating WebSocket extensions This document defines 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 WebSocket data messages on a per-message basis using parameters of WebSocket data messages on a per-message basis using parameters
negotiated during the opening handshake. This framework provides a negotiated during the opening handshake. This framework provides a
general method for applying a compression algorithm to the contents general method for applying a compression algorithm to the contents
of WebSocket messages. Each compression algorithm has to be defined of WebSocket messages. Each compression algorithm has to be defined
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance Requirements and Terminology . . . . . . . . . . . 4 2. Conformance Requirements and Terminology . . . . . . . . . . . 4
3. Complementary Terminology . . . . . . . . . . . . . . . . . . 5 3. Complementary Terminology . . . . . . . . . . . . . . . . . . 5
4. WebSocket Per-message Compression Extension . . . . . . . . . 6 4. WebSocket Per-message Compression Extension . . . . . . . . . 6
5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7 5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 7
5.1. General Negotiation Flow . . . . . . . . . . . . . . . . . 9 5.1. General Negotiation Flow . . . . . . . . . . . . . . . . . 9
5.2. Negotiation Examples . . . . . . . . . . . . . . . . . . . 10 5.2. Negotiation Examples . . . . . . . . . . . . . . . . . . . 10
6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Decompression . . . . . . . . . . . . . . . . . . . . . . 13
7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 15 7. The permessage-deflate extension . . . . . . . . . . . . . . . 15
8. The permessage-deflate extension . . . . . . . . . . . . . . . 16 7.1. Extension Parameters . . . . . . . . . . . . . . . . . . . 16
8.1. Extension Parameters . . . . . . . . . . . . . . . . . . . 17 7.1.1. Context Takeover Control . . . . . . . . . . . . . . . 16
8.1.1. Context Takeover Control . . . . . . . . . . . . . . . 17 7.1.2. Limiting the LZ77 sliding window size . . . . . . . . 18
8.1.2. Limiting the LZ77 sliding window size . . . . . . . . 19 7.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Message Payload Transformation . . . . . . . . . . . . . . 21
8.2. Message Payload Transformation . . . . . . . . . . . . . . 22 7.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 21
8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 22 7.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 22
8.2.2. Decompression . . . . . . . . . . . . . . . . . . . . 23 7.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 27
8.3. Implementation Notes . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9.1. Registration of the "permessage-deflate" WebSocket
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 Extension Name . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Registration of the "permessage-deflate" WebSocket 9.2. Registration of the "Per-message Compressed" WebSocket
Extension Name . . . . . . . . . . . . . . . . . . . . . . 30 Framing Header Bit . . . . . . . . . . . . . . . . . . . . 29
10.2. Registration of the "Per-message Compressed" WebSocket 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
Framing Header Bit . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document specifies a framework for adding compression This document specifies a framework for adding compression
functionality to the WebSocket Protocol [RFC6455]. The framework functionality to the WebSocket Protocol [RFC6455]. The framework
specifies how to define WebSocket Per-message Compression Extensions specifies how to define WebSocket Per-message Compression Extensions
(PMCEs) for a compression algorithm based on the extension concept of (PMCEs) for a compression algorithm based on the extension concept of
the WebSocket Protocol specified in Section 9 of [RFC6455]. A the WebSocket Protocol specified in Section 9 of [RFC6455]. A
WebSocket client and a peer WebSocket server negotiate the use of a WebSocket client and a peer WebSocket server negotiate the use of a
PMCE and determine the parameters required to configure the PMCE and determine the parameters required to configure the
skipping to change at page 6, line 25 skipping to change at page 6, line 25
o The extension name of the PMCE and any applicable extension o The extension name of the PMCE and any applicable extension
parameters that MUST be included in the "Sec-WebSocket-Extensions" parameters that MUST be included in the "Sec-WebSocket-Extensions"
header during the extension negotiation offer/response. header during the extension negotiation offer/response.
o How to interpret the extension parameters exchanged during the o How to interpret the extension parameters exchanged during the
opening handshake. opening handshake.
o How to transform the payload of a message. o How to transform the payload of a message.
One PMCE is defined in Section 8 of this document and is registered One PMCE is defined in Section 7 of this document and is registered
in Section 10. Other PMCEs may be defined in the future in other in Section 9. Other PMCEs may be defined in the future in other
documents. documents.
Section 5 describes the basic extension negotiation process. Section 5 describes the basic extension negotiation process.
Section 6 describes how to apply the compression algorithm with Section 6 describes how to apply the compression algorithm with
negotiated parameters to the contents of WebSocket messages. negotiated parameters to the contents of WebSocket messages.
5. Extension Negotiation 5. Extension Negotiation
To offer use of a PMCE, a client MUST include the extension name of To offer use of a PMCE, a client MUST include the extension name of
the PMCE in the "Sec-WebSocket-Extensions" header field of its the PMCE in the "Sec-WebSocket-Extensions" header field of its
skipping to change at page 15, line 5 skipping to change at page 15, line 5
* If this PMCE is the last extension to process incoming * If this PMCE is the last extension to process incoming
messages, deliver the _A WebSocket Message Has Been Received_ messages, deliver the _A WebSocket Message Has Been Received_
event to the application layer with the received message event to the application layer with the received message
payload and header values as-is. payload and header values as-is.
* Otherwise, pass the message payload and header values to the * Otherwise, pass the message payload and header values to the
extension preceding the PMCE as-is. If the extension expects extension preceding the PMCE as-is. If the extension expects
frames for input, build a frame for the message and pass it. frames for input, build a frame for the message and pass it.
7. Intermediaries 7. The permessage-deflate extension
When an intermediary proxies a WebSocket connection, the intermediary
MAY add, change or remove Per-message Compression of proxied messages
if the intermediary meets all of the following requirements:
o The intermediary understands the PMCE.
o The intermediary can read all data of the proxied WebSocket
connection including the opening handshake request, opening
handshake response, and messages.
o The intermediary can alter the proxied data before forwarding them
in accordance with the constraints of the new combination of
extensions. For example, if Per-message Compression is removed
from messages, the corresponding element in the
"Sec-WebSocket-Extensions" header in the opening handshake
response which enabled the Per-message Compression must also be
removed.
Otherwise, the intermediary MUST NOT add, change or remove Per-
message Compression of proxied messages.
8. The permessage-deflate extension
This section defines a specific PMCE called "permessage-deflate". It This section defines a specific PMCE called "permessage-deflate". It
compresses the payload of a message using the DEFLATE algorithm compresses the payload of a message using the DEFLATE algorithm
[RFC1951] and uses the byte boundary alignment method introduced in [RFC1951] and uses the byte boundary alignment method introduced in
[RFC1979]. [RFC1979].
This section uses the term "byte" with the same meaning as RFC1951, This section uses the term "byte" with the same meaning as RFC1951,
i.e. 8 bits stored or transmitted as a unit (same as an octet). i.e. 8 bits stored or transmitted as a unit (same as an octet).
The registered extension name for this extension is The registered extension name for this extension is
skipping to change at page 17, line 34 skipping to change at page 16, line 34
The term "LZ77 sliding window" used in this section means the buffer The term "LZ77 sliding window" used in this section means the buffer
used by the DEFLATE algorithm to store recently processed input. The used by the DEFLATE algorithm to store recently processed input. The
DEFLATE compression algorithm searches the buffer for a match with DEFLATE compression algorithm searches the buffer for a match with
the following input. the following input.
The term "use context take over" used in this section means that the The term "use context take over" used in this section means that the
same LZ77 sliding window used by the endpoint to build frames of the same LZ77 sliding window used by the endpoint to build frames of the
previous sent message is reused to build frames of the next message previous sent message is reused to build frames of the next message
to be sent. to be sent.
8.1. Extension Parameters 7.1. Extension Parameters
8.1.1. Context Takeover Control 7.1.1. Context Takeover Control
8.1.1.1. The server_no_context_takeover extension parameter 7.1.1.1. The server_no_context_takeover extension parameter
A client MAY include the "server_no_context_takeover" extension A client MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation offer. This extension parameter in an extension negotiation offer. This extension
parameter has no value. By including this extension parameter in an parameter has no value. By including this extension parameter in an
extension negotiation offer, a client prevents the peer server from extension negotiation offer, a client prevents the peer server from
using context take over. If the peer server doesn't use context take using context take over. If the peer server doesn't use context take
over, the client doesn't need to reserve memory to retain the LZ77 over, the client doesn't need to reserve memory to retain the LZ77
sliding window between messages. sliding window between messages.
Absence of this extension parameter in an extension negotiation offer Absence of this extension parameter in an extension negotiation offer
skipping to change at page 18, line 20 skipping to change at page 17, line 20
It is RECOMMENDED that a server supports the It is RECOMMENDED that a server supports the
"server_no_context_takeover" extension parameter in an extension "server_no_context_takeover" extension parameter in an extension
negotiation offer. negotiation offer.
A server MAY include the "server_no_context_takeover" extension A server MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation response even if the extension parameter in an extension negotiation response even if the extension
negotiation offer being accepted by the extension negotiation negotiation offer being accepted by the extension negotiation
response didn't include the "server_no_context_takeover" extension response didn't include the "server_no_context_takeover" extension
parameter. parameter.
8.1.1.2. The client_no_context_takeover extension parameter 7.1.1.2. The client_no_context_takeover extension parameter
A client MAY include the "client_no_context_takeover" extension A client MAY include the "client_no_context_takeover" extension
parameter in an extension negotiation offer. This extension parameter in an extension negotiation offer. This extension
parameter has no value. By including this extension parameter in an parameter has no value. By including this extension parameter in an
extension negotiation offer, a client informs the peer server of a extension negotiation offer, a client informs the peer server of a
hint that even if the server doesn't include the hint that even if the server doesn't include the
"client_no_context_takeover" extension parameter in the corresponding "client_no_context_takeover" extension parameter in the corresponding
extension negotiation response to the offer, the client is not going extension negotiation response to the offer, the client is not going
to use context take over. to use context take over.
skipping to change at page 19, line 5 skipping to change at page 18, line 5
context take over. This reduces the amount of memory that the server context take over. This reduces the amount of memory that the server
has to reserve for the connection. has to reserve for the connection.
Absence of this extension parameter in an extension negotiation Absence of this extension parameter in an extension negotiation
response indicates that the server can decompress messages built by response indicates that the server can decompress messages built by
the client using context take over. the client using context take over.
A client MUST support the "client_no_context_takeover" extension A client MUST support the "client_no_context_takeover" extension
parameter in an extension negotiation response. parameter in an extension negotiation response.
8.1.2. Limiting the LZ77 sliding window size 7.1.2. Limiting the LZ77 sliding window size
8.1.2.1. The server_max_window_bits extension parameter 7.1.2.1. The server_max_window_bits extension parameter
A client MAY include the "server_max_window_bits" extension parameter A client MAY include the "server_max_window_bits" extension parameter
in an extension negotiation offer. This parameter has a decimal in an extension negotiation offer. This parameter has a decimal
integer value without leading zeroes between 8 to 15 inclusive integer value without leading zeroes between 8 to 15 inclusive
indicating the base-2 logarithm of the LZ77 sliding window size and indicating the base-2 logarithm of the LZ77 sliding window size and
MUST conform to the ABNF below. MUST conform to the ABNF below.
server_max_window_bits = 1*DIGIT server_max_window_bits = 1*DIGIT
By including this parameter in an extension negotiation offer, a By including this parameter in an extension negotiation offer, a
skipping to change at page 19, line 46 skipping to change at page 18, line 46
inclusive indicating the base-2 logarithm of the LZ77 sliding window inclusive indicating the base-2 logarithm of the LZ77 sliding window
size and MUST conform to the ABNF below. size and MUST conform to the ABNF below.
server_max_window_bits = 1*DIGIT server_max_window_bits = 1*DIGIT
A server MAY include the "server_max_window_bits" extension parameter A server MAY include the "server_max_window_bits" extension parameter
in an extension negotiation response even if the extension in an extension negotiation response even if the extension
negotiation offer being accepted by the response didn't include the negotiation offer being accepted by the response didn't include the
"server_max_window_bits" extension parameter. "server_max_window_bits" extension parameter.
8.1.2.2. The client_max_window_bits extension parameter 7.1.2.2. The client_max_window_bits extension parameter
A client MAY include the "client_max_window_bits" extension parameter A client MAY include the "client_max_window_bits" extension parameter
in an extension negotiation offer. This parameter has no value or a in an extension negotiation offer. This parameter has no value or a
decimal integer value without leading zeroes between 8 to 15 decimal integer value without leading zeroes between 8 to 15
inclusive indicating the base-2 logarithm of the LZ77 sliding window inclusive indicating the base-2 logarithm of the LZ77 sliding window
size. If a value is specified for this parameter, the value MUST size. If a value is specified for this parameter, the value MUST
conform to the ABNF below. conform to the ABNF below.
client_max_window_bits = 1*DIGIT client_max_window_bits = 1*DIGIT
skipping to change at page 21, line 6 skipping to change at page 20, line 6
If a received extension negotiation offer doesn't have the If a received extension negotiation offer doesn't have the
"client_max_window_bits" extension parameter, the corresponding "client_max_window_bits" extension parameter, the corresponding
extension negotiation response to the offer MUST NOT include the extension negotiation response to the offer MUST NOT include the
"client_max_window_bits" extension parameter. "client_max_window_bits" extension parameter.
Absence of this extension parameter in an extension negotiation Absence of this extension parameter in an extension negotiation
response indicates that the server can receive messages compressed response indicates that the server can receive messages compressed
using an LZ77 sliding window of up to 32,768 bytes. using an LZ77 sliding window of up to 32,768 bytes.
8.1.3. Examples 7.1.3. Examples
The simplest "Sec-WebSocket-Extensions" header in a client's opening The simplest "Sec-WebSocket-Extensions" header in a client's opening
handshake to offer use of the permessage-deflate extension looks like handshake to offer use of the permessage-deflate extension looks like
this: this:
Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Extensions: permessage-deflate
Since the "client_max_window_bits" extension parameter is not Since the "client_max_window_bits" extension parameter is not
included in this extension negotiation offer, the server must not included in this extension negotiation offer, the server must not
accept the offer with an extension negotiation response that includes accept the offer with an extension negotiation response that includes
skipping to change at page 22, line 13 skipping to change at page 21, line 13
server may send back a response as follows: server may send back a response as follows:
Sec-WebSocket-Extensions: Sec-WebSocket-Extensions:
permessage-deflate; server_max_window_bits=10 permessage-deflate; server_max_window_bits=10
To accept the second option, for example, the server may send back a To accept the second option, for example, the server may send back a
response as follows: response as follows:
Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Extensions: permessage-deflate
8.2. Message Payload Transformation 7.2. Message Payload Transformation
8.2.1. Compression 7.2.1. Compression
An endpoint uses the following algorithm to compress a message. An endpoint uses the following algorithm to compress a message.
1. Compress all the octets of the payload of the message using 1. Compress all the octets of the payload of the message using
DEFLATE. DEFLATE.
2. If the resulting data does not end with an empty DEFLATE block 2. If the resulting data does not end with an empty DEFLATE block
with no compression (the "BTYPE" bits are set to 00), append an with no compression (the "BTYPE" bits are set to 00), append an
empty DEFLATE block with no compression to the tail end. empty DEFLATE block with no compression to the tail end.
skipping to change at page 23, line 42 skipping to change at page 22, line 42
LZ77 sliding window with any size to compress messages to send as LZ77 sliding window with any size to compress messages to send as
long as the size conforms to the "agreed parameters". The client-to- long as the size conforms to the "agreed parameters". The client-to-
server "client_max_window_bits" extension parameter is just a hint server "client_max_window_bits" extension parameter is just a hint
for the server to build an extension negotiation response. for the server to build an extension negotiation response.
If the "agreed parameters" contain the "server_max_window_bits" If the "agreed parameters" contain the "server_max_window_bits"
extension parameter with a value of w, the server MUST NOT use an extension parameter with a value of w, the server MUST NOT use an
LZ77 sliding window longer than the w-th power of 2 bytes to compress LZ77 sliding window longer than the w-th power of 2 bytes to compress
messages to send. messages to send.
8.2.2. Decompression 7.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 of the message. payload of the message.
2. Decompress the resulting data using DEFLATE. 2. Decompress the resulting data using DEFLATE.
If the "agreed parameters" contain the "server_no_context_takeover" If the "agreed parameters" contain the "server_no_context_takeover"
extension parameter, the client MAY decompress each new message with extension parameter, the client MAY decompress each new message with
skipping to change at page 24, line 40 skipping to change at page 23, line 40
the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768 the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768
byte LZ77 sliding window to decompress received messages. Note that byte LZ77 sliding window to decompress received messages. Note that
even if the client has included in its offer the even if the client has included in its offer the
"client_max_window_bits" extension parameter with a value smaller "client_max_window_bits" extension parameter with a value smaller
than one in the "agreed parameters", the client MUST use an LZ77 than one in the "agreed parameters", the client MUST use an LZ77
sliding window of a size that conforms the "agreed parameters" to sliding window of a size that conforms the "agreed parameters" to
compress messages to send. The client-to-server compress messages to send. The client-to-server
"client_max_window_bits" extension parameter is just a hint for the "client_max_window_bits" extension parameter is just a hint for the
server to build an extension negotiation response. server to build an extension negotiation response.
8.2.3. Examples 7.2.3. Examples
This section introduces examples of how the permessage-deflate This section introduces examples of how the permessage-deflate
extension transforms messages. extension transforms messages.
8.2.3.1. A message compressed using 1 compressed DEFLATE block 7.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
Huffman code and the "BFINAL" bit not set) to compress the message, Huffman code and the "BFINAL" bit not set) to compress the message,
the endpoint obtains the compressed data to use for the message the endpoint obtains the compressed data to use for the message
payload as follows. payload as follows.
The endpoint compresses "Hello" into 1 compressed DEFLATE block and The endpoint compresses "Hello" into 1 compressed DEFLATE block and
flushes the resulting data into a byte array using an empty DEFLATE flushes the resulting data into a byte array using an empty DEFLATE
block with no compression: block with no compression:
skipping to change at page 26, line 5 skipping to change at page 25, line 5
fragments are 3 and 4 octet, the first frame is: fragments are 3 and 4 octet, the first frame is:
0x41 0x03 0xf2 0x48 0xcd 0x41 0x03 0xf2 0x48 0xcd
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.
8.2.3.2. Sharing LZ77 Sliding Window 7.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. message.
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
The above is the payload of the first message that the client has The above is the payload of the first message that the client has
sent. If the "agreed parameters" contain the sent. If the "agreed parameters" contain the
"client_no_context_takeover" extension parameter, the client "client_no_context_takeover" extension parameter, the client
skipping to change at page 26, line 36 skipping to change at page 25, line 36
of the second message will be: of the second message will be:
0xf2 0x00 0x11 0x00 0x00 0xf2 0x00 0x11 0x00 0x00
So, 2 bytes are saved in total. So, 2 bytes are saved in total.
Note that even if some uncompressed messages (with the RSV1 bit Note that even if some uncompressed messages (with the RSV1 bit
unset) are inserted between the two "Hello" messages, they don't unset) are inserted between the two "Hello" messages, they don't
affect the LZ77 sliding window. affect the LZ77 sliding window.
8.2.3.3. Using a DEFLATE Block with No Compression 7.2.3.3. Using a DEFLATE Block with No Compression
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
This is a frame constituting a text message "Hello" built using a This is a frame constituting a text message "Hello" built using a
DEFLATE block with no compression. The first 2 octets (0xc1 0x0b) DEFLATE block with no compression. The first 2 octets (0xc1 0x0b)
are the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0, are the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0,
opcode=text, MASK=0, Payload length=7). Note that the RSV1 bit is opcode=text, MASK=0, Payload length=7). Note that the RSV1 bit is
set for this message (only on the first fragment if the message is set for this message (only on the first fragment if the message is
fragmented) because the RSV1 bit is set when DEFLATE is applied to fragmented) because the RSV1 bit is set when DEFLATE is applied to
the message, including the case when only DEFLATE blocks with no the message, including the case when only DEFLATE blocks with no
compression are used. The 3rd to 13th octets consist the payload compression are used. The 3rd to 13th octets consist the payload
data containing "Hello" compressed using a DEFLATE block with no data containing "Hello" compressed using a DEFLATE block with no
compression. compression.
8.2.3.4. Using a DEFLATE Block with BFINAL Set to 1 7.2.3.4. Using a DEFLATE Block with BFINAL Set to 1
On platforms on which the flush method using an empty DEFLATE block On platforms on which the flush method using an empty DEFLATE block
with no compression is not available, implementors can choose to with no compression is not available, implementors can choose to
flush data using DEFLATE blocks with "BFINAL" set to 1. flush data using DEFLATE blocks with "BFINAL" set to 1.
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
This is the payload of a message containing "Hello" compressed using This is the payload of a message containing "Hello" compressed using
a DEFLATE block with "BFINAL" set to 1. The first 7 octets a DEFLATE block with "BFINAL" set to 1. The first 7 octets
constitute a DEFLATE block with "BFINAL" set to 1 and "BTYPE" set to constitute a DEFLATE block with "BFINAL" set to 1 and "BTYPE" set to
01 containing "Hello". The last 1 octet (0x00) contains the header 01 containing "Hello". The last 1 octet (0x00) contains the header
bits with "BFINAL" set to 0 and "BTYPE" set to 00, and 5 padding bits bits with "BFINAL" set to 0 and "BTYPE" set to 00, and 5 padding bits
of 0. This octet is necessary to allow the payload to be of 0. This octet is necessary to allow the payload to be
decompressed in the same manner as messages flushed using DEFLATE decompressed in the same manner as messages flushed using DEFLATE
blocks with BFINAL unset. blocks with BFINAL unset.
8.2.3.5. Two DEFLATE Blocks in 1 Message 7.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) constitute one DEFLATE block with bits of the 4th octet (0x00) constitute one DEFLATE block with
"BFINAL" set to 0 and "BTYPE" set to 01 containing "He". The rest of "BFINAL" set to 0 and "BTYPE" set to 01 containing "He". The rest of
the 4th octet contains the header bits with "BFINAL" set to 0 and the 4th octet contains the header bits with "BFINAL" set to 0 and
"BTYPE" set to 00, and the 3 padding bits of 0. Together with the "BTYPE" set to 00, and the 3 padding bits of 0. Together with the
following 4 octets (0x00 0x00 0xff 0xff), the header bits constitute following 4 octets (0x00 0x00 0xff 0xff), the header bits constitute
an empty DEFLATE block with no compression. A DEFLATE block an empty DEFLATE block with no compression. A DEFLATE block
containing "llo" follows the empty DEFLATE block. containing "llo" follows the empty DEFLATE block.
8.2.3.6. Generating an Empty Fragment Manually 7.2.3.6. Generating an Empty Fragment Manually
Suppose that an endpoint is sending data of unknown size. The Suppose that an endpoint is sending data of unknown size. The
endpoint may encounter the end of data signal from the data source endpoint may encounter the end of data signal from the data source
when its buffer for uncompressed data is empty. In such a case, the when its buffer for uncompressed data is empty. In such a case, the
endpoint just needs to send the last fragment with FIN bit set to 1 endpoint just needs to send the last fragment with FIN bit set to 1
and payload set to DEFLATE block(s) which contains 0 bytes of data. and payload set to DEFLATE block(s) which contains 0 bytes of data.
If the compression library being used doesn't generate any data when If the compression library being used doesn't generate any data when
its buffer is empty, an empty uncompressed DEFLATE block can be built its buffer is empty, an empty uncompressed DEFLATE block can be built
manually and used for this purpose as follows: manually and used for this purpose as follows:
0x00 0x00
The only octet 0x00 contains the header bits with "BFINAL" set to 0 The only octet 0x00 contains the header bits with "BFINAL" set to 0
and "BTYPE" set to 00, and 5 padding bits of 0. and "BTYPE" set to 00, and 5 padding bits of 0.
8.3. Implementation Notes 7.3. Implementation Notes
On most common software development platforms, the DEFLATE On most common software development platforms, the DEFLATE
compression library provides a method for aligning compressed data to compression library provides a method for aligning compressed data to
byte boundaries using an empty DEFLATE block with no compression. byte boundaries using an empty DEFLATE block with no compression.
For example, Zlib [Zlib] does this when "Z_SYNC_FLUSH" is passed to For example, Zlib [Zlib] does this when "Z_SYNC_FLUSH" is passed to
the deflate function. the deflate function.
Some platforms may provide only methods to output and process Some platforms may provide only methods to output and process
compressed data with a ZLIB header and an Adler-32 checksum. On such compressed data with a ZLIB header and an Adler-32 checksum. On such
platforms, developers need to write stub code to remove and platforms, developers need to write stub code to remove and
skipping to change at page 28, line 27 skipping to change at page 28, line 5
To obtain a useful compression ratio, an LZ77 sliding window size of To obtain a useful compression ratio, an LZ77 sliding window size of
1,024 or more is RECOMMENDED. 1,024 or more is RECOMMENDED.
If a side disallows context takeover, its endpoint can easily figure If a side disallows context takeover, its endpoint can easily figure
out whether a certain message will be shorter if compressed or not. out whether a certain message will be shorter if compressed or not.
Otherwise, it's not easy to know whether future messages will benefit Otherwise, it's not easy to know whether future messages will benefit
from having a certain message compressed. Implementors may employ from having a certain message compressed. Implementors may employ
some heuristics to determine this. some heuristics to determine this.
8.4. Intermediaries 8. Security Considerations
When an intermediary forwards a message, the intermediary MAY change
the compression of messages provided that the resulting sequence of
messages conforms to the constraints based on the "agreed
parameters". For example, an intermediary may decompress a received
message, unset the "Per-message Compressed" bit and forward it to the
other peer. Since such a compression change may affect the LZ77
sliding window, the intermediary may need to parse and transform the
following messages, too.
9. Security Considerations
There is a known exploit when history-based compression is combined There is a known exploit when history-based compression is combined
with a secure transport [CRIME]. Implementors should pay attention with a secure transport [CRIME]. Implementors should pay attention
to this point when integrating this extension with other extensions to this point when integrating this extension with other extensions
or protocols. or protocols.
10. IANA Considerations 9. IANA Considerations
10.1. Registration of the "permessage-deflate" WebSocket Extension Name 9.1. Registration of the "permessage-deflate" WebSocket Extension Name
This section describes a WebSocket extension name registration in the This section describes a WebSocket extension name registration in the
WebSocket Extension Name Registry [RFC6455]. WebSocket Extension Name Registry [RFC6455].
Extension Identifier Extension Identifier
permessage-deflate permessage-deflate
Extension Common Name Extension Common Name
WebSocket Per-message Deflate WebSocket Per-message Deflate
Extension Definition Extension Definition
This document. This document.
Known Incompatible Extensions Known Incompatible Extensions
None None
The "permessage-deflate" extension name is used in the The "permessage-deflate" extension name is used in the
"Sec-WebSocket-Extensions" header in the WebSocket opening handshake "Sec-WebSocket-Extensions" header in the WebSocket opening handshake
to negotiate use of the permessage-deflate extension. to negotiate use of the permessage-deflate extension.
10.2. Registration of the "Per-message Compressed" WebSocket Framing 9.2. Registration of the "Per-message Compressed" WebSocket Framing
Header Bit Header Bit
This section describes a WebSocket framing header bit registration in This section describes a WebSocket framing header bit registration in
the WebSocket Framing Header Bits Registry [RFC6455]. the WebSocket Framing Header Bits Registry [RFC6455].
Value Value
RSV1 RSV1
Description Description
The message is compressed or not. RSV1 is set for compressed The message is compressed or not. RSV1 is set for compressed
messages and unset for uncompressed messages. messages and unset for uncompressed messages.
Reference Reference
Section 6 of this document. Section 6 of this document.
The "Per-message Compressed" framing header bit is used on the first The "Per-message Compressed" framing header bit is used on the first
fragment of data messages to indicate whether the payload of the fragment of data messages to indicate whether the payload of the
message is compressed by the PMCE or not. message is compressed by the PMCE or not.
11. Acknowledgements 10. 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.
Thanks to the following people who participated in discussions on the Thanks 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): Adam Rice, Alexander Philippou, list is likely to be incomplete): Adam Rice, Alexander Philippou,
Alexey Melnikov, Arman Djusupov, Bjoern Hoehrmann, Brian McKelvey, Alexey Melnikov, Arman Djusupov, Bjoern Hoehrmann, Brian McKelvey,
Dario Crivelli, Greg Wilkins, Inaki Baz Castillo, Jamie Lokier, Dario Crivelli, Greg Wilkins, Inaki Baz Castillo, Jamie Lokier,
Joakim Erdfelt, John A. Tamplin, Julian Reschke, Kenichi Ishibashi, Joakim Erdfelt, John A. Tamplin, Julian Reschke, Kenichi Ishibashi,
Mark Nottingham, Peter Thorson, Roberto Peon, Salvatore Loreto, Mark Nottingham, Peter Thorson, Roberto Peon, Salvatore Loreto,
Simone Bordet, Tobias Oberstein and Yutaka Hirano. Note that people Simone Bordet, Tobias Oberstein and Yutaka Hirano. Note that people
listed above didn't necessarily endorse the end result of this work. listed above didn't necessarily endorse the end result of this work.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for
Sequential Data Compression", IEEE Transactions on Sequential Data Compression", IEEE Transactions on
Information Theory, Vol. 23, No. 3, pp. 337-343. Information Theory, Vol. 23, No. 3, pp. 337-343.
12.2. Informative References 11.2. Informative References
[RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. [RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
[Zlib] Gailly, J. and M. Adler, "Zlib", <http://zlib.net/>. [Zlib] Gailly, J. and M. Adler, "Zlib", <http://zlib.net/>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012, [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", Ekoparty 2012,
September 2012. September 2012.
Author's Address Author's Address
 End of changes. 31 change blocks. 
89 lines changed or deleted 53 lines changed or added

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