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

RE: #300: Define non-final responses

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Tue, 19 Jul 2011 14:54:28 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Greg Wilkins <gregw@webtide.com>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <F1D6C4CA564CA347B3B9EB54BEA5AD7C0CCD7C90@TK5EX14MBXC214.redmond.corp.microsoft.com>
> > Same thing goes for the other samples. In neither of these cases are there any
> additional "GET" request defined by the WebSockets communication -- the HTTP
> upgrade request indeed semantically signifies the interaction with the resource.
> Once you have established the WebSocket you obviously no longer are bound
> to a request/response interaction pattern and so can evolve into any message
> exchange pattern desired but then you clearly are beyond HTTP semantics.
> Well, no, we are still bound by the semantics of HTTP.  We are not bound by the
> interaction limitations of HTTP, its specific syntax, or even the nature of its
> messages.  That's what you mean above, and I agree.

Yes, I meant on subsequent interactions beyond the first one.
> Certainly, if the WebSockets server is using the request target to initiate a
> response to that HTTP request, then the mechanism of that response doesn't
> matter.
> What matters is that the client doesn't need to repeat its request inside the
> WebSockets protocol after the connection is established.  So, if that is true of the
> WebSockets handshake, then it is indeed using Upgrade correctly.

Yup, no need to reinvent GET :)
Received on Tuesday, 19 July 2011 14:55:08 UTC

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