Also I agree with Ian that for communication between a single server and a single client, applications can work out their own "protocol", or some classes of applications (e.g. collaborative editing of some type of structures) can converge on a "protocol".
As far as the client and the server are concerned, negotiating things such as frame length seems rather pointless to me, because: a) we don't have any such negotiation currently for e.g. Web pages or images. b) The client should know the server reasonably well, and for applications where frame length is an issue (e.g. image upload, although I think there are way better ways to do image upload than with WebSockets), an external description of the service may contain some limits, or the "protocol" will say that you have to send the size first and wait for a "uploading is okay" from the server.
Where length issues or the like may come into play may be intermediaries. And (generic) intermediaries are where metadata is most valuable.
That said, however, I also agree with some other people on this list that extension points should be considered carefully. Greg's proposal:
> 1) WS should allow arbitrary headers in the upgrade request/response > > 2) WS should define a frame type for transport meta data, whose > content is defined only as Mime (or just mime headers). > The semantics of these can be left to other protocols built > on top of WS. seems to be a very good starting point. Regards, Martin. On 2009/10/30 6:51, Greg Wilkins wrote:
Rory Byrne wrote:In a further effort to boost our chances of building robust WebSocket servers, I would hope that we might consider adding some sort of maximum frame length negotiation. Nothing fancy, there could be a suitable default maximum, and a 'Max-Frame-Length' header which enables a client to negotiate a higher maximum. Maybe something like this: GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com WebSocket-Protocol: sample Max-Frame-Length: 2097152 HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample Max-Frame-Length: 1048576 The server would only send a 'Max-Frame-Length' header if it wanted to set the maximum to be lower than the client suggested. Any thoughts?I think having the ability to negotiate such parameters is a good way to fail fast if a server and client are not compatible (eg client needs to send larger messages than server is willing to receive). But I'm sure that there will be resistance to having such negotiation as a mandatory part of the protocol. However, the problem with making this kind of negotiation optional (and this goes for my earlier examples of a load balancer communicating SSL info and/or node stickyness), is that the current WS protocol has no place for meta data to be added in an optional manner - so that it can be ignored by implementations that don't care. Ian has previously said that instead of adding headers to the Upgrade request/response, messages should be injected into the stream to communicate this meta data. However, because there is no way to flag these messages as meta data, simple implementations are going to try to handle them as messages. This limitation of no standard meta-data paths, means that it is nigh impossible to introduce features like multiplexing, load balancing, fragmentations, HTTP transport etc. as optional additional specifications built on top of ws. Because there is no meta channel, simple implementations will treat everything as a message and break if there is any new protocol layered on top. This is SO simple to fix: 1) WS should allow arbitrary headers in the upgrade request/response 2) WS should define a frame type for transport meta data, whose content is defined only as Mime (or just mime headers). The semantics of these can be left to other protocols built on top of WS. With these 2 simple additions, then we could later develop a standards that (for example): + implement multi-plexing by negotiated support in the upgrade request/response and then injecting a meta data packet, before each data packet, containing the information needed to route the subsequent data message. + implement standards to send content advisory messages that would contain info such as language, content-type etc for a connection. These could be used by implementations that wanted to be flexible, or ignored by implementations that are sure they know what they are connecting to. The current proposal is just too nailed down. There is no where to insert any optional handling. The API is wired to the TCP/IP layer. The handshake messages are locked down to binary equivalence. There are spare framing types available - but any suggestions to allocate that space for meta-data have been rejected. It appears that the whatwg want layered protocols to be controlled by the allocation of frame byte values to them and only officially sanctified extensions will get the nod. The Whatwg needs to loosen up and realize that it should not try to completely control how a protocol will be used in the wild (eg an not force all servers to be 100 line perl scripts). They have to allow it some room to breath and grow. They need to allocate some space for some arbitrary meta data to be used or ignored as implementations see fit. regards _______________________________________________ hybi mailing list hybi at ietf.org https://www.ietf.org/mailman/listinfo/hybi
-- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.