anchor.diff:  	end.
   ----
   
  -It is not recommended to wait too long inside the `init/2`
  -function. Any extra initialization may be done after returning by
  -sending yourself a message before doing anything. Any message sent
  -to `self()` from `init/2` is guaranteed to arrive before
  -any frames from the client.
  -
  -It is also very easy to ensure that this message arrives before
  -any message from other processes by sending it before registering
  -or enabling timers.
  -
  -// @todo This doesn't even work.
  -
  -[source,erlang]
  -----
  -init(Req, State) ->
  -	self() ! post_init,
  -	%% Register process here...
  -	{cowboy_websocket, Req, State}.
  -
  -websocket_info(post_init, State) ->
  -	%% Perform post_init initialization here...
  -	{ok, State}.
  -----
  -
  -=== Handling frames from the client
  +=== Post-upgrade initialization
  +
  +Cowboy has separate processes for handling the connection
  +and requests. Because Websocket takes over the connection,
  +the Websocket protocol handling occurs in a different
  +process than the request handling.
  +
  +This is reflected in the different callbacks Websocket
  +handlers have. The `init/2` callback is called from the
  +temporary request process and the `websocket_` callbacks
  +from the connection process.
  +
  +This means that some initialization cannot be done from
  +`init/2`. Anything that would require the current pid,
  +or be tied to the current pid, will not work as intended.
  +The optional `websocket_init/1` can be used instead:
  +
  +[source,erlang]
  +----
  +websocket_init(State) ->
  +	erlang:start_timer(1000, self(), <<"Hello!">>),
  +	{ok, State}.
  +----
  +
  +All Websocket callbacks share the same return values. This
  +means that we can send frames to the client right after
  +the upgrade:
  +
  +[source,erlang]
  +----
  +websocket_init(State) ->
  +	{reply, {text, <<"Hello!">>}, State}.
  +----
  +
  +=== Receiving frames
   
   Cowboy will call `websocket_handle/2` whenever a text, binary,
  -ping or pong frame arrives from the client. Note that in the
  -case of ping and pong frames, no action is expected as Cowboy
  -automatically replies to ping frames.
  -
  -The handler can decide to send frames to the socket, stop
  -or just continue without sending anything.
  +ping or pong frame arrives from the client.
  +
  +The handler can handle or ignore the frames. It can also
  +send frames back to the client or stop the connection.
   
   The following snippet echoes back any text frame received and
  -ignores all others.
  +ignores all others:
   
   [source,erlang]
   ----
  
positive.code: 		undefined ->
  			{ok, Req, State};
  		Subprotocols ->
  			case lists:keymember(<<"mychat2">>, 1, Subprotocols) of
  				true ->
  					Req2 = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>,
  						<<"mychat2">>, Req),
  					{ok, Req2, State};
  				false ->
  					{stop, Req, State}
  
negative.code: 	{cowboy_websocket, Req, State}.
  ----
  
  Cowboy will perform the Websocket handshake immediately. Note
  that the handshake will fail if the client did not request an
  upgrade to Websocket.
  
  The Req object becomes unavailable after this function returns.
  Any information required for proper execution of the Websocket
  handler must be saved in the state.
  
  === Subprotocol
  
  The client may provide a list of Websocket subprotocols it
  supports in the sec-websocket-protocol header. The server *must*
  select one of them and send it back to the client or the
  handshake will fail.
  
  For example, a client could understand both STOMP and MQTT over
  Websocket, and provide the header:
  
  ----
  sec-websocket-protocol: v12.stomp, mqtt
  ----
  
  If the server only understands MQTT it can return:
  
  ----
  sec-websocket-protocol: mqtt
  ----
  
  This selection must be done in `init/2`. An example usage could
  be:
  
  [source,erlang]
  ----
  