IETF Logo Mail Archive

Re: [hybi] Are HTTP bodies allowed in Websocket client handshakes?

Andy Green <andy@warmcat.com> Wed, 01 November 2023 07:26 UTC

Return-Path: <andy@warmcat.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 27D7CC1522AD for <hybi@ietfa.amsl.com>; Wed, 1 Nov 2023 00:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=warmcat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vALY9c9s5Kzt for <hybi@ietfa.amsl.com>; Wed, 1 Nov 2023 00:26:37 -0700 (PDT)
Received: from mog.warmcat.com (mog.warmcat.com [178.170.10.5]) by ietfa.amsl.com (Postfix) with ESMTP id 49599C151073 for <hybi@ietf.org>; Wed, 1 Nov 2023 00:26:36 -0700 (PDT)
Received: from mx.warmcat.com (host31-53-7-249.range31-53.btcentralplus.com [31.53.7.249]) by mog.warmcat.com (Postfix) with ESMTPSA id 6AEAC135BEE; Wed, 1 Nov 2023 07:26:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mog.warmcat.com 6AEAC135BEE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warmcat.com; s=default; t=1698823594; bh=VOPp4KmsWNiCZJUZG/7+im96V25d0iOx///53WvUbJg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=hBbduRctgwgJ2mNkjTERQWcoiMq7C4ymPehL396ACbCFL1fVEExfYgFMF5jDK9ik4 S3cNg05H4kzf4hkBsnl/12abNQ8CctAi5adHVYyj6P7EmK4VfvzPHAQP8zGMPmE5Vn Iwc9tQd0ifWZN+wX3K4VO/HkVpwAGwM0xxt6mtZo=
Received: from [10.199.0.166] (unknown [10.199.0.166]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mx.warmcat.com (Postfix) with ESMTPSA id 0B6B1224DC; Wed, 1 Nov 2023 07:26:34 +0000 (UTC)
Message-ID: <c7c1bc46-4eff-4087-954d-c478de999a3b@warmcat.com>
Date: Wed, 01 Nov 2023 07:26:33 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Emile Cormier <emile.cormier.jr@gmail.com>, hybi@ietf.org
References: <CAM70yxBLYpf9uG=z2eAmQhRQgPvzvMWDC+vBPYEnq=Cqw7+9Bg@mail.gmail.com>
From: Andy Green <andy@warmcat.com>
In-Reply-To: <CAM70yxBLYpf9uG=z2eAmQhRQgPvzvMWDC+vBPYEnq=Cqw7+9Bg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/wfre_KnVRiefMrqSdxgghfihfwM>
Subject: Re: [hybi] Are HTTP bodies allowed in Websocket client handshakes?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 01 Nov 2023 07:26:43 -0000


On 10/31/23 22:22, Emile Cormier wrote:
> Hi,
> 
> As per the subject, are HTTP bodies allowed in Websocket client 
> handshakes? Should the server ignore them, or treat their presence as a 
> protocol error? Web searches don't bring up anything about this question.

At the time of the UPGRADE request, the connection is purely http still, 
so whatever you can send with UPGRADE and how to send it there is 
defined outside of ws.

https://datatracker.ietf.org/doc/html/rfc9110#name-upgrade

doesn't seem to talk about if you can send a body either, however it 
does say

   A client cannot begin using an upgraded protocol on the connection
   until it has completely sent the request message (i.e., the client
   can't change the protocol it is sending in the middle of a message).

"completely sent the request message" sounds like it would include any 
pointless body that went out with the request message IIUI, implying the 
server should swallow the body before replying.  IOW "UPGRADE request" 
includes any redundant body sent with it.

In the case that the upgrade succeeds, data after the "UPGRADE request" 
will switch to ws protocol.  The server will interpret any data after 
the "UPGRADE request" as ws protocol data.

  - UPGRADE req no body -> server doesn't consume body -> OK
  - UPGRADE req no body -> server consumes body -> OK
  - UPGRADE req + body -> server doesn't consume body -> broken conn
  - UPGRADE req no body -> server consumes body -> OK

In the case the upgrade is denied, the connection remains in http. 
There shouldn't be any leftover unconsumed body from the earlier failed 
UPGRADE request to pipeline into as the next transaction, so again it 
seems the server should eat any body with the upgrade request before 
replying.

At least, that's my understanding.

> The RFC only uses the term "body" in relation to close, ping, and pong 
> frames
-Andy

> Cheers,
> Emile Cormier
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

v2.23.0 | Report a Bug | By Email