On Fri, 05 Sep 2008 14:42:45 +0200, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking <[EMAIL PROTECTED]>
wrote:
http://foo.com
and
http://foo.com:80
are the same origin but have different string representations.
Yes, authors would have to use the former. (The former is also what
Origin will tell them as well.)
I might be missing some context here... but use the former where,
exactly?
In the Access-Control-Allow-Origin header.
Would a page loaded from the latter not be able to do AC stuff?
That wouldn't matter.
In general, I think forcing authors to think about whether the port is
included is really poor practice and sounds like it would break
real-world systems (e.g. any system that wants to run HTTP servers on
multiple ports and just always specifies ports everywhere instead of
specifying 8080 but not 80).
Handling this in UAs is almost certainly reasonably straightforward
(have to replace string compares with origin object compares, with the
objects doing port normalization as needed). It doesn't seem like it
would be hard to deal with in the spec either, though obviously it's a
bit more work than just not dealing. So I'm not sure why we want to
break the long-standing (and imo obvious per the relevant RFCs)
convention that you get the same behavior for http:// no matter whether
the port is explicitly listed as 80.
That sounds reasonable. What's currently specified is equivalent to what
HTML 5 specifies for the WebSocket protocol. It seemed reasonable to keep
the two synchronized somewhat though maybe they should both change.
Though do note that the value authors get (through the Origin header) will
be without the default port so authors will have to deal with this anyway.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
