Re: wrt HTTP Origin header serialization (was Re: The HTTP Sec-From Header (draft-abarth-origin))

On Tue, Oct 27, 2009 at 4:31 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> serialization rules in draft-abarth-origin wrt a "scheme/host/port tuple"
> yield a tuple looking like..
>
>  scheme://host:port
>
> Earlier in this thread someone asked about what would happen if one
> dereferenced such a string, and the answer was (I am paraphrasing here)
> "don't do that, it isn't a URI".
>
> However, syntactically, it *is* a URI.

In the sense that pretty much anything with a ":" in it is a URI, we
would worry what happens if someone dereferences a Content-Length: 87
"URI".  :)

More seriously, whether or not it looks like a URI, it's not a URI.

> I suggest that a serialized origin ought to have a syntax that is not
> syntactically a URI, e.g. pick some separator char that allows for
> reasonable parsing (i.e. won't be confused with whatever might appear in a
> <host> production (which can contain IPv4 and IPv6 address serializations)),
> such as perhaps...
>
>  scheme/host/port, or
>  scheme#host#port, or
>  scheme?host?port, or
>  scheme@host@port
>
> ..i.e. the <gen-delim> values from RFC3986 that aren't included in the
> IP-literal, IPvFuture, IPv6address, reg-name, etc productions (that <host>
> depends upon).

The syntax was chosen to match the HTML postMessage API, which has
shipped in all major browsers.  I think it's unlikely we'll change the
syntax now without a very compelling reason.

Adam