Hey Alexey,
Thanks for following up. A couple of responses inline.
--Richard
[Is GET/Upgrade appropriate?]
It seems like the use of GET here goes beyond the normal "safe" semantics
for that method. To quote RFC 2616:
"
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval.
"
In addition, alternative protocols specified in Upgrade headers are
generally optional, whereas in this case, the transaction fails overall if
the server does not support the websocket protocol. It doesn't look to me
like any of the current methods provide much better semantics (except
possiblyCONNECT or the use of OPTIONS as in RFC 2817), and it seems like
defining a new method could help get around the Upgrade issue as well.
This issue was discussed extensively in the WG and was reraised during IETF
LC by others. I will followup with a more detailed answer (or maybe the WG
agrees with you and this would be changed), but a quick comment on one of the
points.
The WG discussed defining a new HTTP method, but the idea didn't have the
support of majority because new HTTP methods are hard to deploy (due to old
intermediaries which don't handle them as well as they should have if they
were compliant with RFC 2616).
What's the argument against CONNECT? It seems like that's exactly what is
desired here -- for proxies to act as tunnels. RFC 2817 uses an upgrade to TLS
in all its examples, but the is specified more generally:
"
Any successful (2xx) response to a CONNECT request indicates that the
proxy has established a connection to the requested host and port,
and has switched to tunneling the current connection to that server
connection.
"
It seems like this gets you around the threat that masking is supposed to
address -- the proxy won't see anything mid-stream that looks like HTTP, since
it's just acting as a tunnel at that point. It's a little weird to use CONNECT
end-to-end, but that doesn't seem bad enough to be a blocking issue.
[Huge buffers]
The frame length can be 7, 16, or 64 bits long. Since the client is
expected to buffer data until the end of a frame, this is asking clients to
buffer 128 B, 64 KB, or 16 EB. If it were 32 bits, the max would be 4 MB.
Why not just make this a 32-bit fixed length field?
This was discussed in the WG. On one hand the frame length encoding is
optimized for packet size (the field overhead is small for smaller packets)
and on another hand there was a desire to support big buffer sizes, thus the
current proposal. I believe a single 32bit field was proposed but was
explicitly decided against.
Actually, now that I think about it, aren't you solving the same problem twice,
once with frame length and once with fragmentation? If the goal is to have the
browser buffer for me until my whole message has arrived, isn't that met by
either a giant frame or fragmentation? Given that, it seems like having a
16-bit field would even be sufficient. It seems like 64k will probably cover a
lot of applications (64k should be enough for anyone!), and for large things
that use fragmentation, the header overhead would only be 8 octets per 64k, way
down in the noise. (3 octets if you get rid of masking!)
[Unlimited buffering with fragmentation]
Much like with the frame length issue above, the fragmentation mechanism
here seems like it imposes a heavy burden on the receive side. Since the
receiving client is supposed to buffer data until the end of a frame, it
seems like fragmentation could be used to cause a receiving client to buffer
a frame of indefinite size.
This is not really different from what other protocols like HTTP and SMTP
already allow. I think it would be fair to note this in the Security
Considerations section, but I don't think this feature should be removed.
Fragmentation does allow senders to start sending data before the total size
of the object is known (e.g. if data is generated on the fly), which was
considered as an important feature by the WG.
A mention in the Security Considerations sounds like a sensible solution to me.
Minor issues:
[Setting protocol]
In the NOTE in Section 1.3, the document observes that Sec- headers can't be
set in XHRs. But clearly the Sec-WebSocket-Protocol header can be set
through some API that applications use to get to this protocol. So it seems
a little misleading to imply that scripts can't set these headers (besides
-Version and -Origin).
But a script can't set the Sec-WebSocket-Protocol header field value directly.
That's not really true: You can't set it *directly*, in the sense that the
following is not allowed:
client.setRequestHeader("Sec-WebSocket-Protocol", "kick-puppies");
But you can set it by setting the protocols in the WebSocket API:
var ws = new WebSocket("ws://evil.tld/kick-puppies", ["kick-puppies"]);
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf