- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sun, 17 Jul 2011 18:07:43 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Jul 17, 2011, at 5:53 PM, Mark Nottingham wrote: > Roy, if I understand correctly, you're saying that the server is still responsible for responding to the request, whatever wire protocol that it chooses to use. That is, when you say "response" you're speaking in a general, semantic way, not response-message-serialised-as-HTTP. Yes, that is the requirement in HTTP. > Other folks are saying that what happens after an upgrade is a complete black box, which HTTP cannot say anything about. Perhaps they are unfamiliar with STD 3. > From the standpoint of (for example) a HTTP/1.1 intermediary, the latter view is true (and I note that a lot of people participating in this discussion are intermediary implementers). No, it isn't true. Upgrade is a hop-by-hop field and the intermediary will only upgrade the connection if they are capable of doing so. Part of being capable is knowing how to fulfill the request. > However, I agree that from the user-agent and origin server's perspective, the request is still outstanding until the server satisfies it -- however it chooses to do so. > > Roy's view makes a lot of sense when you consider Upgrade as a way to transition to a protocol like SPDY, which closely mirrors HTTP's semantics. It doesn't fit as obviously with less HTTP-like protocols (e.g., WebSockets), but conceptually, the request is either fulfilled or not. Other protocols that do not want GET semantics, or some other such semantically significant method, should use something like OPTIONS for the request and specify how to respond to it. That is what I told the hybi WG. > What we need to do is find a way to communicate this so it's clear in both contexts. The requirement already exists. Maybe we just need to move it up. ....Roy
Received on Monday, 18 July 2011 01:08:07 UTC