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

Re: #300: Define non-final responses

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 17 Jul 2011 22:59:39 +0000
To: Bjoern Hoehrmann <derhoermi@gmx.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <23013.1310943579@critter.freebsd.dk>
In message <jio627t392ai6p0nod1702u88ejhvlgvuj@hive.bjoern.hoehrmann.de>, Bjoer
n Hoehrmann writes:
>* Poul-Henning Kamp wrote:
>>There is absolutely no support in the text for the notion that
>>the server should send a 200 reponse between the 101 and the
>>switch of protocol.
>
>My impression is that the issue is whether you can have a HTTP
>request that goes unanswered and then have meaningful exchanges
>on the same connection. Is HTTP a "request-response" protocol, or
>a "request and then either response or protocol switch" protocol?

The 101 _is_ your HTTP reponse, but it is not the reponse to
your request.

The reason for this little dance is to avoid an extra round-trip:

Instead of:
	> GET / HTTP/1.1
	> Upgrade: Wiz-Bang

	< HTTP/1.1 101 Protocol switch
	< Upgrade: Wiz-Bang

	> [wiz-bang GET /]
	< [wiz-bang index.html]

We can:
	> GET / HTTP/1.1
	> Upgrade: Wiz-Bang

	< HTTP/1.1 101 Protocol switch
	< Upgrade: Wiz-Bang

	< [wiz-bang OK index.html]

However, if the protocol is not for delivering web-objects it may
instead look like:

	> GET / HTTP/1.1
	> Upgrade: TN3270

	< HTTP/1.1 101 Protocol switch
	< Upgrade: TN3270

	< [TELNET option negotiation]


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 17 July 2011 23:00:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:45 GMT