[
https://issues.apache.org/jira/browse/WICKET-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853464#comment-13853464
]
Joakim Erdfelt commented on WICKET-5453:
----------------------------------------
Some more points of concern with WicketFilter ...
Chrome 32 (due out soon) is more strict on Subprotocol validation.
If a request from a client contains a Sec-WebSocket-Protocol then the server
*MUST* respond with one of the provided protocols or fail the upgrade.
RFC 6455 - Section 4.4 / http://tools.ietf.org/html/rfc6455#section-4.4
If you have a Sec-WebSocket-Version header, but it doesn't contain version 13
then you should respond with error 400.
I know that section 4.2.2 says you can optionally choose to send response code
426 (but few websocket clients support that properly as that response code is
not part of RFC 2616 spec)
You should also detect Sec-WebSocket-Draft and
Sec-WebSocket-Key1/Sec-WebSocket-Key2 headers to give proper errors for Safari
5.x (either from OSX or IOS) or Flash clients.
> Jetty 9.1.0 has its own UpgradeFilter, use it
> ---------------------------------------------
>
> Key: WICKET-5453
> URL: https://issues.apache.org/jira/browse/WICKET-5453
> Project: Wicket
> Issue Type: Bug
> Components: wicket-native-websocket
> Affects Versions: 7.0.0
> Reporter: Joakim Erdfelt
> Assignee: Martin Grigorov
> Priority: Minor
>
> In a recent stackoverflow question ..
> http://stackoverflow.com/questions/20661139/websocket-timeout-with-apache-wicket-and-embedded-jetty
> I noticed a reference to a class called Jetty9WebSocketFilter
> Starting in Jetty 9.1.0, a filter for websocket upgrade ships with Jetty.
> See answer (with example code):
> http://stackoverflow.com/a/20663447/775715
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
