[hybi] "Cache-Control: no-cache" may improve handshake success rate

Takeshi Yoshino <tyoshino@google.com> Mon, 01 October 2012 05:33 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF921F8588 for <hybi@ietfa.amsl.com>; Sun, 30 Sep 2012 22:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.716
X-Spam-Level:
X-Spam-Status: No, score=-101.716 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWQcR8sst6i2 for <hybi@ietfa.amsl.com>; Sun, 30 Sep 2012 22:33:10 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45A21F84F5 for <hybi@ietf.org>; Sun, 30 Sep 2012 22:33:09 -0700 (PDT)
Received: by iec9 with SMTP id 9so13011001iec.31 for <hybi@ietf.org>; Sun, 30 Sep 2012 22:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=iJjlDx/D0KKFMgYf780uiE+O11KKCJBilbriU05WHl0=; b=J818JjUrrmKuP5rQ1vNV0raSjJHieDeByPJNUCprCpdBRWkU6ytJx1ilGj99DA+wxy 7M7PA2w78EVto2i1BsgG5G65f4ezac56JKivFy21ylifLVdsJzjsFp3Hi78zzggb9jCy 0ixp0rFRfcNqhFVh8JiMtJ+hhUmpF3WZIAKWEM3rtfJeigfjssvH9Jk9quyHBhS/TpWv WFqCRaJ88VQwJ9jQpegQosXk66/JtaiAPqP4gfOD4J/VxZXRiqI6fqswBZFSvAkoL3tX j16D8sQuqn1KMnC/rIpLobVk4HarQJFFuMxdFmT+KzWg3ho63R4et0Ano+amnbP60+/t A1mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=iJjlDx/D0KKFMgYf780uiE+O11KKCJBilbriU05WHl0=; b=AdJsFS64HPclsLSMhuyJ1KaCaf1liUKO1AnWu+7CF+d9worY55St6xxS/LBl/hRSzF Xqa2wNj8gi4THeCT+77yB1q7DX853ge1ibuQbn92C5glsYHaL8nWYO8gn+0/Mew4REc7 wb5xOfMVajPaqeJ1ZJXUBRUjALTRCaA43iG59ZgE74QyMk6Z7RlQ7aEHSlZ+DLg66vJt pj8UpXhHWOAMgqHPPHGGySFcS/V5Cmj8B2VY9CTBY3BYaktYgrw5LNYUKwNjrIMGNxsW QZ/IVSC0HO7eJ8dJIP7d20P8V+PlCpTgk7YH+/bkaWrqo6ECpIFsJsby+Qhco6bZB40+ 1KtA==
Received: by 10.50.237.69 with SMTP id va5mr4666373igc.55.1349069589340; Sun, 30 Sep 2012 22:33:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.82.140 with HTTP; Sun, 30 Sep 2012 22:32:49 -0700 (PDT)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Mon, 01 Oct 2012 14:32:49 +0900
Message-ID: <CAH9hSJZc8z+dxjpKm8rnAJXXoEdgTT87NJ2NjP5E2wnr8J_L-Q@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="14dae93409a5a6628904caf8bdf2"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkqSCb0JCHahNi8ASxbVX4CMyFmRLXSv/czgE2hnscnFRqUMTYT6oMJ6VUt+JyVRwVPGs3a0qekTJLJQOTXoGcLkJKyg79OT3kXL/bcLtegKZDWIJj3t81l5FS4dSlzfv2lLkCN5gLCWlmVhpcks6UhePydJlUcz7picZiEF/2Mu57GKiwxL9KtlgflMQyKxX9xmcIN
Subject: [hybi] "Cache-Control: no-cache" may improve handshake success rate
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 01 Oct 2012 05:33:11 -0000

It seems adding the Cache-Control header to the WebSocket handshake
improves success rate for some environment.

We've investigated one bug report [1] for Chrome, and found that there're
some caches deployed in Thailand which corrupt server's opening handshakes
by replacing the value in the Connection header with close.

This doesn't happen if Firefox is used. Some tests using reduced header set
indicated that it's because Firefox puts the Cache-Control and Pragma
header like this:

Pragma: no-cache
Cache-Control: no-cache

in its WebSocket client's handshakes while Chrome does not send such
headers.

I guess that the proxy is caching server's opening handshake and sending
the cached data but after overwriting the Connection header ignoring the
meaning of "Connection: Upgrade".

Basically, we want Upgrade non-compliant proxies to be replaced with new
ones rather than taking work around, but don't have much reluctance to use
of the headers.

----

[1] http://code.google.com/p/chromium/issues/detail?id=148908. Thanks
bangkokmaco.