:method | Re: WebSocket2

[Kari Hurtta <[e-mail]>]

Van Catha <[e-mail]>: (Mon Oct  3 19:39:34 2016)
> Amos Jeffries
> 
> > I believe the relevant expert(s) are reading this thread already.
> >
> > That is the more likely reason a negotiated extension is unlikely to
> > happen. If it is not needed at all, then it might be easier not to bother.
> 
> I was not aware using a custom method was allowed, if that is the case,
> CONNECT, UPGRADE, WS2, etc all work.

• Using CONNECT makes this

 ":scheme"    = "wss"  (or  "ws"  on forward proxy scenario )
 ":authority" = "foo.example"
 ":method"    = "CONNECT"
 ":path"      = "/bar"

RFC of Websocket2  updates RFC 7540 (HTTP/2)

This make clear negation for WebSocket2

https://tools.ietf.org/html/rfc7540#section-8.3

|   o  The ":method" pseudo-header field is set to "CONNECT".
|
|   o  The ":scheme" and ":path" pseudo-header fields MUST be omitted.
|
|   o  The ":authority" pseudo-header field contains the host and port to
|      connect to (equivalent to the authority-form of the request-target
|      of CONNECT requests (see [RFC7230], Section 5.3)).
|
|   A CONNECT request that does not conform to these restrictions is
|   malformed (Section 8.1.2.6).
 
https://tools.ietf.org/html/rfc7540#section-8.1.2.6

|   Intermediaries that process HTTP requests or responses (i.e., any
|   intermediary not acting as a tunnel) MUST NOT forward a malformed
|   request or response.  Malformed requests or responses that are
|   detected MUST be treated as a stream error (Section 5.4.2) of type
|   PROTOCOL_ERROR.
|
|   For malformed requests, a server MAY send an HTTP response prior to
|   closing or resetting the stream.  Clients MUST NOT accept a malformed
|   response.  Note that these requirements are intended to protect
|   against several types of common attacks against HTTP; they are
|   deliberately strict because being permissive can expose
|   implementations to these vulnerabilities.


1) If origin server, forward proxy or reserve proxy
   supports HTTP/2 and pay attention and does not
   support WebSocket2, then it produces RST_STREAM 
   or GOAWAY frame with PROTOCOL_ERROR.

   RST_STREAM is cheap but GOAWAY is expensive.

2) If origin server notices ":method", but ignores
   ":scheme" and ":path", this produces 
   ":status" = "405"   (Method Not Allowed) most likely.

3) If reverse proxy for ":authority" notices ":method", 
   but ignores ":scheme" and ":path", then it perhaps just
   forwards request (maybe dropping ":scheme" and ":path")

4) If forward proxy configured on browser notices ":method", 
   but ignores ":scheme" and ":path", then it perhaps tries connect port
   443 of ":authority" or perhaps it notices that port is missing
   from ":authority".

• Using WS2 makes this

 ":scheme"    = "wss"  (or  "ws"  on forward proxy scenario )
 ":authority" = "foo.example"
 ":method"    = "WS2"
 ":path"      = "/bar"

RFC of Websocket2 registers new method. 

( http://www.iana.org/assignments/http-methods/http-methods.xhtml#methods )
( Registration Procedure(s): IETF Review
  RFCs (of IETF working group) and some other RFCs 
  fills that procedure. )

This is similar than PRI method registeration of
RFC 7540 (HTTP/2)

https://tools.ietf.org/html/rfc7540#section-11.6

|   Related information:  This method is never used by an actual client.
|      This method will appear to be used when an HTTP/1.1 server or
|      intermediary attempts to parse an HTTP/2 connection preface.

WS2 is not used as actual http -method but it is used on negotiation.

If origin server, forward proxy or reserve proxy does
not pay attention to ":scheme" and ":method", it 
probbaly assumes that DATA frames form HTTP request
and response body.

1) If origin server does not pay attention to ":scheme"
   it  produces ":status" = "405"  (Method Not Allowed) most likely.

2) If origin server notices that it does not support
   ":scheme" it can also produce ":status" = "501" (Not Implemented).

3) Reverse proxy for ":authority" probably forwards request
   but may assume that DATA frames form HTTP request
   and response body if it does not know about 
   RFC of Websocket2.

4) forward proxy configured on browser proabably
   notices that it does not support ":scheme"
   and returns ":status" = "501" (Not Implemented)
   (in case it does not support or know about
    RFC of Websocket2).

• Using UPGRADE is same case than WS2

RFC of Websocket2 registers new method.

/ Kari Hurtta