- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 27 Oct 2009 20:22:31 -0700
- To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Wednesday, 28 October 2009 03:23:30 UTC