/irc-logs / w3c / #webapps / 2008-07-22 / end
Options:
- # Session Start: Tue Jul 22 00:00:00 2008
- # Session Ident: #webapps
- # [00:10] * Quits: mjs (mjs@24.5.43.151) (Quit: mjs)
- # [00:11] * Joins: mjs (mjs@24.5.43.151)
- # [00:11] * Quits: mjs (mjs@24.5.43.151) (Connection reset by peer)
- # [00:16] * Joins: sicking (chatzilla@63.245.220.241)
- # [00:16] <sicking> Hixie, ping
- # [00:23] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [00:25] <Hixie> sicking: poing
- # [00:26] <sicking> Hixie, so trying to get the URL issue for AC resolved. Want to ensure that MS doesn't stray away out of fear of the spec being unstable
- # [00:27] <sicking> Hixie, what is the advantage of using HTML urls for AC?
- # [00:27] <Hixie> no idea
- # [00:27] <Hixie> i wasn't really away that it was being used
- # [00:27] <Hixie> aware, even
- # [00:27] <Hixie> where is it used?
- # [00:28] <sicking> in the syntax for the Access-Control-Allow-Origin header
- # [00:28] <Hixie> uri?
- # [00:28] <Hixie> wait, in the syntax for a header? server->client, or client->server?
- # [00:28] <sicking> server->client for sure, not sure about client->server
- # [00:29] <sicking> the syntax for Access-Control-Allow-Origin is (url | "*")
- # [00:29] <sicking> with url pointing to the html5 spec
- # [00:29] * Hixie wishes anne would link to dev.w3.org from the TR/ copy of the draft
- # [00:30] <Hixie> i can never find these specs
- # [00:30] <sicking> http://dev.w3.org/2006/waf/access-control/
- # [00:30] <Hixie> thanks
- # [00:30] <sicking> use a browser with a decent bookmarking system
- # [00:30] <sicking> ;)
- # [00:30] * sicking loves the new one-click bookmarks in FF3
- # [00:31] <Hixie> i use too many machines and too many browsers and blow away my profiles too often for bookmarks to actually do me any good
- # [00:31] <Hixie> ok
- # [00:31] <Hixie> so anyway
- # [00:31] <Hixie> URL in the syntax seems to be fine
- # [00:31] <Hixie> it just means it has to be a URI
- # [00:31] <sicking> a valid one, or a parseable one?
- # [00:32] <Hixie> i had assumed valid, since it's defining the syntax, not the parsing, but come to think of it, it doesn't actually say either way, does it
- # [00:32] <Hixie> the term "URL" in HTML5 isn't a syntax, it's just any arbitrary string used as an address
- # [00:32] <Hixie> so that's a bug in AC
- # [00:34] <sicking> i'd argue we should point to rfc 3986 instead
- # [00:35] <Hixie> sounds fine with me
- # [00:35] <Hixie> we need to make sure we define exactly how to parse everything
- # [00:35] <Hixie> with 3986 doesn't say
- # [00:35] <sicking> oh? :(
- # [00:36] <Hixie> s/with/which/
- # [00:36] <sicking> what do you mean by 'everything'? every valid value, or every possible value?
- # [00:36] <Hixie> 3986 doesn't define any kind of error handling
- # [00:36] <Hixie> and it makes certain things errors that i'm sure most people don't consider errors
- # [00:36] <Hixie> which is fine, but we need to say then that any kind of error must cause a failure, or whatever
- # [00:37] <sicking> agreed
- # [00:37] <Hixie> (and we have to test the hell out of it, since this is a security feature)
- # [00:37] <sicking> yup, we should set up a test server
- # [00:38] * Quits: heycam (cam@124.168.13.237) (Quit: bye)
- # [00:52] * Joins: marcos (marcos@192.76.14.61)
- # [00:55] * Quits: marcos (marcos@192.76.14.61) (Ping timeout)
- # [01:12] <sicking> Hixie, mind commenting on the list since you know this stuff better than me
- # [01:14] <Hixie> not sure what to say
- # [01:14] <Hixie> i don't know what anne wanted
- # [01:15] <sicking> Hixie, i think what he wanted was to ensure that uris weren't parsed differently if they showed up in the header rather than a html page
- # [01:15] <sicking> Hixie, especially if that could lead to security problems
- # [01:17] * Joins: heycam (cam@130.194.72.84)
- # [01:18] <Hixie> well if we change how they are parsed, they will be parsed differently
- # [01:19] <sicking> but we want that, no?
- # [01:19] <Hixie> i don't really know
- # [01:19] <Hixie> i haven't been following the AC stuff closely enough
- # [01:19] <sicking> ok, i guess i'll comment
- # [01:21] <sicking> does the html5 spec have a definition of what a *valid* uri/url/iri or some such is?
- # [01:22] <Hixie> yeah
- # [01:22] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#valid
- # [01:22] <sicking> hmm..
- # [01:23] <sicking> so the spec says that all URLs live in the context of a Document
- # [01:23] <sicking> AC headers do not though...
- # [01:23] <sicking> so can we even refer to the HTML5 spec at all here?
- # [01:23] <Hixie> not naively, no
- # [01:24] <Hixie> i mean, we probably need to for the XHR spec
- # [01:24] <sicking> so cearly we need to chane the AC spec
- # [01:24] <Hixie> but i'm not sure what it even means to refer to HTML5 in the context of the AC spec
- # [01:24] <sicking> *clearly
- # [01:24] <sicking> agreed
- # [01:25] <sicking> Hixie, does the same apply to the terms 'same origin' and 'origin'?
- # [01:26] * Joins: mjs (mjs@17.203.15.152)
- # [01:26] <sicking> Hixie, from the AC spec: The terms URL, parse a URL, origin, ASCII serialization of an origin, same origin ... are defined by HTML 5. [HTML5]
- # [01:26] <Hixie> that would be a "naive" use of html5
- # [01:27] <Hixie> he probably needs to do something like what the Web Workers spec does
- # [01:27] <Hixie> and define the base URL and origin URL
- # [01:27] <mjs> sicking: I don't think the angle brackets are particularly bad, but we can making parsing of extensions unambiguous without them, but anne is on vacation so I'd rather stick with what we have than leave the issue open til he gets back
- # [01:27] <sicking> well, URL parsing also uses the Document charset
- # [01:27] <Hixie> indeed, he'd have to define the charset, etc
- # [01:28] <sicking> mjs, i'm not at all married to the idea of angle brackets, whitespace is fine too
- # [01:28] <sicking> mjs, well, we need to give MS something they can implement sooner than 3 weeks from now :(
- # [01:28] <mjs> sicking: right, so I say stick with no angle brackets
- # [01:29] <mjs> (Apple needs something sooner than 3 weeks from now too)
- # [01:29] <sicking> as do we
- # [01:29] <mjs> I think spec + anne's latest email is reasonable and implementable
- # [01:29] <sicking> Hixie, and strictly speaking, the URL parsing also needs a Document as it's written now
- # [01:29] <mjs> (though a bit rough for Microsoft's purposes maybe)
- # [01:29] <Hixie> sicking: indeed
- # [01:30] <sicking> Hixie, but i guess that can be fixed in the HTML5 spec
- # [01:30] <Hixie> actually parsing doesn't
- # [01:30] <Hixie> i think you mean resolving
- # [01:31] <sicking> Hixie, the spec says that URLs are always associated with a Document. It doesn't qualify it to just resolving
- # [01:32] <Hixie> oh _URLs_ always need a Document, yes
- # [01:32] <Hixie> actually what they really need is an encoding, but I get that from the Document when you're resolving it
- # [01:32] <Hixie> parsing a url doesn't need that document
- # [01:33] <sicking> Hixie, seems very confusing to say that parsing URLs is fine without a document, but URLs are not
- # [01:33] <sicking> Hixie, though at this point it's just editorial issues IMHO
- # [01:33] <Hixie> yeah i should clean that up
- # [01:34] <Hixie> doesn't matter in html5 itself since you always have a document :-)
- # [01:34] <sicking> mjs, actually, i think the spec currently (with annes emails) does allow whitespace as part of the domain name
- # [01:34] <Hixie> i should probably make the encoding make more sense for workers though
- # [01:34] <mjs> sicking: "allow" as in parsing will handle it, or "allow" as in it is considered valid syntax?
- # [01:35] <mjs> sicking: I would be ok with rejecting anything that's not a valid per-RFC URL in this context
- # [01:35] <sicking> mjs, spec doesn't seem to make a distinction
- # [01:35] <sicking> mjs, agreed, but we need the spec to state that
- # [01:36] <Hixie> if anne used my "resolve a url" steps, spaces in a hostname would get nuked in step 7, since spaces fail to go through ToASCII, iirc.
- # [01:36] <Hixie> at least i hope they do
- # [01:36] <sicking> the spec is woefully lacking details as of now
- # [01:39] <Hixie> yeah ToASCII fails on spaces, assuming "verify that" is supposed to be like an assert (RFC3490)
- # [01:40] <sicking> so i'm still unsure what to do even for my implementation
- # [01:40] <sicking> as in, should i take the whole header value and apply the parsing algorithm to it?
- # [01:41] <sicking> or should i verify against RFC 3986 syntax first and reject if it's not valid per that rfc?
- # [01:42] * Quits: smaug (chatzilla@82.181.141.13) (Quit: ChatZilla 0.9.83 [Firefox 3.0.1pre/2008062923])
- # [01:42] <Hixie> if our goal is to ensure that the server is intentionally allowing a scheme-host-port combination, then i say verify that it's a URI (an absolute one) with a scheme, a host, a part, and nothing else (no path, e.g.)
- # [01:42] <Hixie> and then check to see if the three parts match what you expect
- # [01:43] <mjs> spaces in hostnames are not allowed in any case
- # [01:44] <mjs> or in the scheme or port
- # [01:44] <Hixie> i should make WebSocket's processing of WebSocket-Origin be stricter
- # [01:44] <mjs> so if the URL has no path but still has a space, then it can't possibly match the origin
- # [01:44] <sicking> true
- # [02:29] * Quits: aroben (aroben@71.58.56.76) (Connection reset by peer)
- # [03:00] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [03:00] * Joins: Hixie (ianh@129.241.93.37)
- # [03:04] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [03:05] * Joins: Hixie (ianh@129.241.93.37)
- # [03:06] * Joins: harry (kcome@58.213.221.207)
- # [03:17] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [03:18] * Joins: Hixie (ianh@129.241.93.37)
- # [03:24] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [03:32] * Parts: scotfl_ (scotfl@70.64.14.62)
- # [03:34] * Joins: aroben (adamroben@76.111.160.14)
- # [03:56] * Quits: sicking (chatzilla@63.245.220.241) (Connection reset by peer)
- # [05:26] * Quits: mjs (mjs@17.203.15.152) (Ping timeout)
- # [06:11] * Quits: weinig (weinig@17.203.14.159) (Quit: weinig)
- # [07:47] * Joins: weinig (weinig@71.198.176.23)
- # [07:53] * Quits: weinig (weinig@71.198.176.23) (Connection reset by peer)
- # [07:53] * Joins: weinig (weinig@71.198.176.23)
- # [08:31] * Quits: arve (arve@80.203.77.192) (Quit: Leaving)
- # [08:55] * Quits: heycam (cam@130.194.72.84) (Ping timeout)
- # [09:32] * Quits: aroben (adamroben@76.111.160.14) (Quit: aroben)
- # [10:09] * Joins: tlr (tlr@128.30.52.30)
- # [10:18] * Quits: Dashiva (noone@80.202.223.209) (Quit: Dashiva)
- # [10:18] * Joins: arve (arve@213.236.208.22)
- # [11:12] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [11:12] * Joins: heycam (cam@124.168.13.237)
- # [11:32] * Joins: smaug (chatzilla@82.181.141.13)
- # [11:53] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [11:57] * Joins: hendry (hendry@89.16.172.32)
- # [11:59] * Joins: Lachy (Lachlan@85.196.122.246)
- # [12:01] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [12:10] <hendry> shouldn't it be "We put Apps on the Web"?
- # [12:13] * Joins: Lachy (Lachlan@213.236.208.22)
- # [12:15] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [12:15] * Joins: Hixie (ianh@129.241.93.37)
- # [12:25] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [12:25] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [12:26] * Joins: Hixie (ianh@129.241.93.37)
- # [12:39] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [12:41] * Joins: Hixie (ianh@129.241.93.37)
- # [12:55] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [12:55] * Joins: Hixie (ianh@129.241.93.37)
- # [13:09] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
- # [13:11] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [13:19] * Quits: chaals (chaals@84.77.12.104) (Quit: chaals)
- # [13:22] <arve> hm, can't reach w3.org
- # [13:22] <tlr> works from here
- # [13:22] <tlr> what kind of error do you get?
- # [13:23] <tlr> ("here" being DSL access in Lux.)
- # [13:23] <arve> hm, works again
- # [13:23] <arve> just no response at all
- # [13:23] * tlr wonders if there's some network problems going on around MIT -- IRC seems flaky for lots of folks recently
- # [14:12] * Quits: heycam (cam@124.168.13.237) (Ping timeout)
- # [14:15] * Joins: heycam (cam@124.168.13.237)
- # [14:42] * Joins: arve_ (arve@213.236.208.247)
- # [14:44] * Quits: arve (arve@213.236.208.22) (Ping timeout)
- # [14:58] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [15:01] * Joins: Lachy (Lachlan@213.236.208.22)
- # [15:12] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
- # [15:14] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [16:08] * Joins: aroben (adamroben@76.111.160.14)
- # [16:09] * Quits: aroben (adamroben@76.111.160.14) (Client exited)
- # [16:10] * Joins: aroben (adamroben@76.111.160.14)
- # [16:57] * Quits: gavin (gavin@63.245.208.169) (Quit: leaving)
- # [16:58] * Joins: gavin (gavin@63.245.208.169)
- # [17:31] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [17:46] * Joins: Lachy (Lachlan@85.196.122.246)
- # [18:35] * Quits: harry (kcome@58.213.221.207) (Ping timeout)
- # [18:57] * Joins: harry (kcome@58.217.139.20)
- # [19:31] * Joins: gavin__ (gavin@63.245.208.169)
- # [19:31] * Quits: gavin (gavin@63.245.208.169) (Connection reset by peer)
- # [19:45] * Quits: weinig (weinig@71.198.176.23) (Quit: weinig)
- # [19:58] * Quits: harry (kcome@58.217.139.20) (Ping timeout)
- # [20:12] * Joins: weinig (weinig@17.203.14.159)
- # [20:14] * Joins: davidb_ (davidb@142.150.154.101)
- # [20:14] * davidb_ is now known as davidb
- # [20:15] * Parts: davidb (davidb@142.150.154.101)
- # [20:58] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
- # [21:05] * Joins: Lachy (Lachlan@85.196.122.246)
- # [22:08] * Joins: mjs (mjs@24.5.43.151)
- # [22:09] * Joins: mjs_ (mjs@24.5.43.151)
- # [22:09] * Quits: mjs (mjs@24.5.43.151) (Connection reset by peer)
- # [23:58] * Joins: mjs (mjs@24.5.43.151)
- # [23:58] * Quits: mjs_ (mjs@24.5.43.151) (Connection reset by peer)
- # Session Close: Wed Jul 23 00:00:00 2008
The end :)