W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #300: Define non-final responses

From: Brian Pane <brianp@brianp.net>
Date: Sun, 17 Jul 2011 15:26:02 -0700
Message-ID: <CAAbTgTtOki7r-jdXs=D15H1prcDSkwxYuRymRJouqrpiGs0JwQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Looking at section 10.1 of RFC 2616, I see two issues that could
benefit from clarification:

1. After a 101, is the server required to send a response to the
original HTTP request in the new protocol?

By my reading of Section 10.1.2, the answer is "no."  Roy's
description, though, suggests that the intended answer was "yes."  And
there's at least one strong argument in favor of requiring the server
to send a final response in the new protocol after the 101: doing so,
rather than requiring the client to retransmit the request in the new
protocol, saves a network round trip.

2. After the server sends a 101, can it send other 1xx responses on
the same connection?

Section 10.1 says "yes," but that seems like a bad idea; once the
server has committed to supporting a different protocol, requiring the
client to accept additional HTTP/1.1 response headers on that
connection would make the client implementation much more complex.

Received on Sunday, 17 July 2011 22:26:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC