https://bz.apache.org/bugzilla/show_bug.cgi?id=56026
--- Comment #15 from Mark Thomas <ma...@apache.org> --- You'll have to take up your concerns over the API with the WebSocket EG. Although given there has been no WebSocket activity at all for Java EE 8 that might be a slow process. Tomcat's starting position is always going to be implementing the spec. Where there are ambiguities then the following priority order of sources is usually followed: - what is in the spec document - what is in the Javadoc - what was discussed by the EG No, this isn't ideal but it is the best we have. This isn't the first instance of a Java EE spec doing something that the user community thinks is just plain wrong. The coercion rules for EL comes to mind as an obvious example. What we have done in the past is to add on option to enable the desired behaviour. Depending on circumstances the option may be a system property (applies to all web apps) or per web app. The default behaviour also varies. It is worth noting that in the thread that is no longer accessible from the java.net (and I can't find a new location) I also mentioned that some refactoring had made implementing this a lot easier in Tomcat. What hasn't changed is that a number of questions remain open such as how many messages to accept before starting to reject them? If there is interest, I suggest re-opening this issue as an enhancement request to optionally enable the desired behaviour. I'll note that enhancement requests with patches tend to get looked faster than those without. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
