Header spec, as briefly said in issue #4198<https://code.google.com/p/go/issues/detail?id=4198>
As I'm using this implementation to run our new websocket at my company, on
which many different partners will connect using client implementations
that may not support sending origin headers, I'd like to contribute on
working to fix that issue and support the whole origin spec described in
RFC6454 <http://tools.ietf.org/html/rfc6454> and
http://tools.ietf.org/html/rfc6455#page-18
Here are the interesting bit:
7.1 <http://tools.ietf.org/html/rfc6454#section-7.1>. Syntax
The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC 3986 <http://tools.ietf.org/html/rfc3986>
and:
8. The request MUST include a header field with the name |Origin|
[RFC6454 <http://tools.ietf.org/html/rfc6454>] if the request is coming from a browser client. If
the connection is from a non-browser client, the request MAY
include this header field if the semantics of that client match
the use-case described here for browser clients. The value of
this header field is the ASCII serialization of origin of the
context in which the code establishing the connection is
running. See [RFC6454 <http://tools.ietf.org/html/rfc6454>] for the details of how this header field
value is constructed.
Based on those, the updated code would:The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC 3986 <http://tools.ietf.org/html/rfc3986>
and:
8. The request MUST include a header field with the name |Origin|
[RFC6454 <http://tools.ietf.org/html/rfc6454>] if the request is coming from a browser client. If
the connection is from a non-browser client, the request MAY
include this header field if the semantics of that client match
the use-case described here for browser clients. The value of
this header field is the ASCII serialization of origin of the
context in which the code establishing the connection is
running. See [RFC6454 <http://tools.ietf.org/html/rfc6454>] for the details of how this header field
value is constructed.
1. Change Config.Origin to an array of URL, as a client may provide more
than one origin.
2. Check if the header exists
3. If it does: Parse it, and fill the Origin list
4. It it doesn't, or if the origin is the string "null": Leave the array
empty
The issue with that is that any implementation currently using the
Config.Origin field would now fail due to the type change.
I do already have some code, but I'd like to check with everyone if that
the above is okay, or how we can make it better.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
