FAQ
Right now, the websocket server in go.net doesn't support the whole Origin
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:

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.

Search Discussions

  • Mikio Hara at Apr 23, 2013 at 1:53 pm
    https://codereview.appspot.com/8731044/ there and waiting for more
    expert review, fyi.

    On Tue, Apr 23, 2013 at 8:26 PM, wrote:
    Right now, the websocket server in go.net doesn't support the whole Origin
    Header spec, as briefly said in issue #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 and
    http://tools.ietf.org/html/rfc6455#page-18

    Here are the interesting bit:
    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

    and:
    8. The request MUST include a header field with the name |Origin|
    [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] for the details of how this header field
    value is constructed.

    Based on those, the updated code would:

    Change Config.Origin to an array of URL, as a client may provide more than
    one origin.
    Check if the header exists
    If it does: Parse it, and fill the Origin list
    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.
    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 23, '13 at 11:44a
activeApr 23, '13 at 1:53p
posts2
users2
websitegolang.org

2 users in discussion

Crobin: 1 post Mikio Hara: 1 post

People

Translate

site design / logo © 2022 Grokbase