Re: WebSocket2

On Sat, Oct 01, 2016 at 03:18:49PM -0400, Van Catha wrote:
> > Is there request header to request no caching? There is certainly a
> > response header to request no caching.
> 
> I believe there is no request that can specify "don't cache", but I may be
> wrong.
> 
> > Or perhaps use a dedicated method? It would seem pretty obivous that
> > if you see a unknown method, you shouldn't assume very much about what
> > it is.
> 
> I think adding/using an unconventional method will be way beyond the scope
> of what
> is presented.  I do not think anyone will implement that?

Well, if one uses https://, then Websockets connections definitely have
unconventional semantics.
 
> > Unfortunately, HTTP/2 does not have strict scheme handling like I
> > proposed. With it, one could just have directly used the wss scheme
> > (or ws for oppsec) and be done with it.
> 
> :scheme is perfect! Wow.  If we could pass ws/wss for example as the scheme
> that
> fits perfectly. Looking at https://tools.ietf.org/html/rfc3986#section-3.1
> the spec for schemes
> it seems ws and wss are perfectly valid schemes to use and are registered;
> http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.

The problem with :scheme is that without the strict handling, you can
get oddball HTTP responses for unknown schemes.

But I guess it could be OK if you had extra response header to indicate
that the server supports WS and intends to establish one (no need for
request header, as the :scheme already impiles intent to establish a WS
connection).

> If we wanted to pass ws2, we would have to register the scheme which I think
> should not be a problem.  As ws2 will not be backwards compatible with
> ws/wss.  Would wss2 need to be included as well in this case?

I would say that WS2 would be a bad idea here, and one should reuse the
already-defined Websockets schemes.
 
> Where is the problem in HTTP/2 that would disallow schemes different from
> http and https, I do not see
> anything related to this?

Well, it doesn't disallow other schemes, just that servers might do odd
things with them (like e.g. ignore the scheme, treating it as https://).

> > It seems to me that using https:// GET here is rather dangerous. Even with
> > extra custom headers.
> 
> Any alternative suggestion?

Well, two above.


-Ilari

Received on Sunday, 2 October 2016 05:08:56 UTC