IETF Logo Mail Archive

[hybi] With deflate-stream, Close frame doesn't work as an end of data marker

Takeshi Yoshino <tyoshino@google.com> Thu, 17 February 2011 02:20 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF443A6D72 for <hybi@core3.amsl.com>; Wed, 16 Feb 2011 18:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.226
X-Spam-Level:
X-Spam-Status: No, score=-105.226 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgxKaOgVu88A for <hybi@core3.amsl.com>; Wed, 16 Feb 2011 18:20:14 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1C5CC3A6CE5 for <hybi@ietf.org>; Wed, 16 Feb 2011 18:20:13 -0800 (PST)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p1H2Kgk8018040 for <hybi@ietf.org>; Wed, 16 Feb 2011 18:20:42 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297909242; bh=xP5RGGX3XqJS9fyXLIEY7Z5f3yw=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=vFSGrOycHPYiwq37fGH/Di3h2RRUo2UIjhkBxHSMCtj6SCWjQwyy9YZNKcqvAVK8m wxgNKBJzcOw/D1kBE25Lw==
Received: from iyb39 (iyb39.prod.google.com [10.241.49.103]) by kpbe16.cbf.corp.google.com with ESMTP id p1H2JNmL014221 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 16 Feb 2011 18:20:41 -0800
Received: by iyb39 with SMTP id 39so2361844iyb.15 for <hybi@ietf.org>; Wed, 16 Feb 2011 18:20:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=YeCYQfmc8BDbQBZRDTbnb2qnNddaVj+L4xf8Z8u4918=; b=hn+te+j1YelNGRq+wzEE4MGrVC4ZDA27wI4Wx5djJsYd4AFMVdPuBp96bS68nvy6Mj PdpO/xlvYithHeMgTw7Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=K+9nmGH9WadizwAEL4A13coYW9QCAqYMPhIOa8gW3edTtoBMBJWSDhB0REkbdghlZy RuToWJExpeNkBUpTL0KA==
Received: by 10.231.39.73 with SMTP id f9mr1146242ibe.79.1297909241135; Wed, 16 Feb 2011 18:20:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.17.201 with HTTP; Wed, 16 Feb 2011 18:20:18 -0800 (PST)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Wed, 16 Feb 2011 18:20:18 -0800
Message-ID: <AANLkTimyGWacfoVFon1TsQzqmsEcKy9tNsmKhCnJhgWM@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="0003255752fe44c2ab049c710b7c"
X-System-Of-Record: true
Subject: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Feb 2011 02:20:15 -0000

It's still under discussion if it's really necessary (see "Clarify the role
of closing handshake" thread), but RST suppression was one of the original
objectives of Close frame. Close frame assures no more data is coming on the
underlying channel to allow the endpoint to close(2) safely.

deflate-stream extension in -05 applies deflate on whole octets of a frame
including the header. If we simply use zlib's flush, we can spoil this
function of Close frame. There can be some data remain not processed/recv-ed
even after getting a Close frame uncompressed.

e.g.
(if Z_SYNC_FLUSH is used) possibly a few octets containing EoB symbol, 3-bit
header, padding, and then BTYPE=00 block "00 00 ff ff".
(if Z_FINISH is used) possibly one octet containing EoB symbol.

Endpoints need to drain these octets to prevent RST. This should be noted.

Takeshi

v2.23.0 | Report a Bug | By Email