Hi Richard,
Thanks for the review. I will answer to some of your comments and I or
my co-editor will followup on remaining issues later on.
Richard L. Barnes wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-hybi-thewebsocketprotocol-10.txt
Reviewer: Richard Barnes
Review Date: 19 July 2011
IETF LC End Date: 25 July 2011
IESG Telechat date: (if known) -
Summary:
Not ready.
Major issues:
[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).
[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.
[Why is masking necessary?]
I seriously question the necessity of the masking of data frames. As I
understand it, the goal is to prevent proxies that don't understand Upgrade
from confusing WebSocket data with HTTP data. This risk seems a little dubious
to me; has such a poisoning attack been demonstrated? It seems like there are
much simpler ways of doing this, like using a method other than GET (either
CONNECT or something new).
I am not a good person to answer this, but believe me the WG debated
this very issue for weeks.
[Why only client-to-server masking?]
Why isn't masking required on server-to-client frames?
As above.
[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.
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.
[snip]
I will also look at your editorial proposals.
Best Regards,
Alexey
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf