Hi Everyone,
I'm new to this list.
Just wanted to jump in here and throw my support in with the server
developers who want to see a byte count on all frames.
I think that Greg Wilkins is right on the money in what he says
about managing server resources. A byte count which tells a server
how much data a client intends to push to it, is a critical piece
of information. We're talking about servers that are going to have
many thousands of clients permanently connected to them for weeks,
or months, on end. To stay alive, these servers will need to be
excellent at resource management. IMO, the protocol as it stands
at the moment, is not giving these servers the information they
require to enable them to adequately manage their resources.
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?
On the whole, I'm really excited about this effort to introduce the
Web Socket protocol. It's great to see that there's buy-in from browser
developers, and I'm really looking forward to testing out their
implementations!
Thanks,
Rory
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.