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

From: =JeffH <[email-masked]>
Date: Tue, 27 Oct 2009 16:31:50 -0700

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.

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).

=JeffH

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Oct 2009 20:22:31 -0700

On Tue, Oct 27, 2009 at 4:31 PM, =JeffH <[email-masked]> wrote:
> serialization rules in draft-abarth-origin wrt a "scheme/host/port tuple"
> yield a tuple looking like..
>
>  scheme://host:port
>
> dereferenced such a string, and the answer was (I am paraphrasing here)
> "don't do that, it isn't 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.

> 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
>

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