- From: Greg Wilkins <gregw@mortbay.com>
- Date: Sat, 08 Aug 2009 21:32:24 +1000
Jonas Sicking wrote: > On Fri, Aug 7, 2009 at 10:07 PM, Greg Wilkins<gregw at mortbay.com> wrote: > Out of curiosity, what advantages do you see with having a declared > content-type? I can think of a few, but wanted to know which ones you > had in mind. There are several reasons and use-cases. Firstly, it's always good to be self describing, so that assumptions can be checked and errors/incompatibilities quickly discovered. I also dislike the "favoured son" status of utf-8 in the websocket protocol proposal. Who's to say that other charsets might not be better for some purposes or that utf-8 might be replaced in the lifespan of the protocol. While not supported by the current js API, I can see imagine uses for a stream of media datagrams (sound bites or chat room avatars). It would be good to be able to mix JPG, PNG etc in the same stream. Currently with XHR in JS, the browser can use the content type to parse a response into XML DOM, HTML, JSON etc. I can imagine extensions to the websocket API that would use similar capabilities. > Also, what do you mean by "orderly close"? Currently one of the pain points in HTTP is that a server can close a connection at any time. So browsers need to be careful when reusing an idle connection as the server might close it just as a new message is sent - then the browser does not know if the message was received or not, so we get the different handling for POST vs GET (idempotency etc.). So what I proposed in BWTP is to support an orderly close interaction, so that a client, server OR intermediary can initiate a close of the connection without losing any in transit messages. Of course, connections can still fail without orderly close - but that will be seen as a real failure rather than a happenstance of normal operation. > As far as specification style (BNF or not), I personally don't really > care there, as long as it's well defined how to handle all possible > inputs, valid or invalid. One aspect of the websocket protocol spec that I don't like, is how it specifies the protocol as an algorithm that is step by step and includes exact hex pattern of some of the messages. eg 6. Send the following bytes to the remote side (the server): 47 45 54 20 Send the /resource name/ value, encoded as US-ASCII. 20 48 54 54 50 2f 31 2e 31 0d 0a 55 70 67 72 61 64 65 3a 20 57 65 62 53 6f 63 6b 65 74 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 61 64 65 0d 0a 7. Send the following bytes: 48 6f 73 74 3a 20 Send the /host/ value, encoded as US-ASCII. 0d 0a 8. Send the following bytes: 4f 72 69 67 69 6e 3a 20 which represents GET <resource name> HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: <host> Origin: But it represents that exactly and does not allow variation that is perfectly legal HTTP. It would allow a server to reject a message simply because it's headers are ordered differently or if a just LF was sent instead of CRLF or if there ever is a HTTP/1.2 or if some extra white space is included in the headers So a server could reject: GET <resource name> HTTP/1.1 Host:<host> Connection:Upgrade Upgrade:WebSocket Origin: and a human debugger who is used to normal HTTP is going to be very very confused why their legal HTTP request is being rejected. This strikes me as an unreasonable restriction to have in the specification. BNF specifications can be a lot more forgiving. It is also really hard to tell what the websocket algorithm specifies. Can you tell me if 3.2 Data Framing and 4.3 Data framing specify the same framing or not? The text is not the same - so potentially the framing is different? What if a client/server produces a legal byte stream but that uses a different algorithm to that specified (eg the bytes are buffered rather that "sent" at each step). Is that client/server considered compliant to the specification? Sorry for ranting, but I think the language and style used by a specification is really important. > Other than that I largely agree. Cool! cheers
Received on Saturday, 8 August 2009 04:32:24 UTC