| 00:10 | <Hixie> | we still need to pick a format for the manifest |
| 00:10 | <Hixie> | i guess that's next on the todo list |
| 00:13 | <othermaciej> | all available options suck |
| 00:14 | <Dashiva> | The unavailable ones suck too :) |
| 00:18 | <othermaciej> | why choose the lesser of two evils? |
| 00:18 | <othermaciej> | I say go all out and base the syntax on ASN.1 |
| 00:18 | <Hixie> | dare i ask |
| 00:18 | <Dashiva> | ASN.1 isn't so bad |
| 00:20 | <Hixie> | i have three requirements so far: |
| 00:20 | <Hixie> | * Has a magic signature |
| 00:20 | <Hixie> | * Has a simple defined processing that is easy to test the error handling of |
| 00:20 | <Hixie> | * Can express two lists of URIs and one mapping of prefixes to URIs |
| 00:21 | <Hixie> | oh i and i suppose i should add "supports a comment syntax" |
| 00:21 | <othermaciej> | the last requirement would rule out JSON, if it is truly a requirement |
| 00:21 | <othermaciej> | leaving XML or ad-hoc plaintext format |
| 00:21 | <Hixie> | i think it is, with big apps i can certainly imagine needing to comment which set of files is required for what |
| 00:22 | <Hixie> | i mean, even my simple .htaccess files often end up quite well documented |
| 00:22 | <Dashiva> | Let's use .htaccess then. mod_rewrite can handle the prefixes :D |
| 03:31 | <Hixie> | if i have a section "cache" for files that have to be cached, what would you call the section for files that are whitelisted as being online only and should never be cached? |
| 03:33 | <othermaciej> | online, live, network, notcached |
| 03:34 | <Hixie> | http://junkyard.damowmow.com/297 |
| 03:37 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#manifests |
| 03:40 | <Hixie> | i think i'm gonna go with "idea #3" there (the same as .../297) unless someone has a better idea by the time i get online next (probably an hour from now) |
| 03:42 | <tantek> | consider reusing terminology from HTTP headers regarding caching? |
| 03:42 | <Hixie> | like what? |
| 03:43 | <Hixie> | i don't think http really has equivalent concepts |
| 03:44 | <tantek> | no-cache ? |
| 03:45 | <Hixie> | this isn't really about the resource not getting cached -- there are various ways in which it could get cached -- it's about the cache being bypassed when you do a request for the resource |
| 03:45 | <Hixie> | the application cache, that is |
| 03:45 | <Hixie> | the normal cache still gets hit |
| 03:45 | <tantek> | http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 |
| 03:45 | <Hixie> | e.g. so that you can have a worked thread that talks to the server even from an "offline" application |
| 03:45 | <tantek> | oh weird |
| 03:46 | <Hixie> | worker thread, rather |
| 03:46 | <tantek> | well I think from an HTTP perspective, they're just different caches |
| 03:46 | <Hixie> | right |
| 03:46 | <tantek> | like layers thereof |
| 03:46 | <tantek> | proxies like |
| 03:46 | <Hixie> | indeed |
| 03:46 | <tantek> | so you should still be able to model it using HTTP, even if it is an "application cache" |
| 03:48 | <Hixie> | well an application cache isn't really an http cache -- the whole point is that normally any resource will avoid the network if it's in the manifest, and any resource not in the manifest will immediately fail, unless it's on this whitelist, in which case it does normal http caching semantics on the browser's primary cache and uses the network if appropriate |
| 03:48 | <Hixie> | no-cache means "bypass all caches" |
| 03:48 | <Hixie> | which isn't what's going on here |
| 03:48 | <Hixie> | i think maciej's "network" suggestion is probably best |
| 03:48 | <Hixie> | anyway, gotta go |
| 03:49 | <Hixie> | bbiab |
| 09:23 | <hsivonen> | should I expect datatemplates to be stable enough to start working on conformance checking them? |
| 09:29 | <hsivonen> | "The contents of rule elements form a template, and may be anything that, when the parent datatemplate is applied to some conforming data, results in a conforming DOM tree." is that supposed to be machine-checkable? |
| 09:31 | <annevk> | I guess it is, but it seems rather tricky as it may involve additional requests, etc. |
| 09:31 | <hsivonen> | also, it involves computing all possible context trees for a selector... |
| 09:33 | <annevk> | isn't that infinite most of the time? |
| 09:33 | <annevk> | '*' |
| 09:33 | <hsivonen> | gotta love how a "small" change can totally break fundamental assumptions about the nature of computations for conformance checking... |
| 09:33 | <hsivonen> | annevk: obviously, enumerating the trees is futile |
| 09:34 | <hsivonen> | I haven't yet figured out what problem data templates solve |
| 09:34 | <hsivonen> | on the first look it seems like XSLT lite with Selectors instead of XPath |
| 09:35 | <annevk> | I'm not sure either, although I'm told it likely replaces repetition templates and looks like XUL templating but simpler |
| 09:37 | <hsivonen> | this stuff looks much harder to grok than repetition templates |
| 09:38 | <hsivonen> | "When an element has a template attribute but no ref attribute, the element may, instead of its usual content model, have a single element of any kind. That element is then used as the root node of the data for the template." aargh |
| 09:39 | <annevk> | You slowly begin to understand why Hixie advocates a no-schema approach |
| 09:40 | <hsivonen> | annevk: well, I guess he has more knowledge of what kind of radical changes he is going to pull off |
| 09:40 | <annevk> | true |
| 09:40 | <hsivonen> | annevk: earlier, analyzing the spec and deciding to use RELAX NG was a reasonable choice |
| 09:40 | <annevk> | http://developer.mozilla.org/en/docs/XUL_Tutorial:Templates has an intro to XUL templates that seems to map to <datatemplatE> and co |
| 09:42 | <annevk> | with a complex structure it should be possible to generate your weblog out of your Atom feed, as I understand it :) |
| 09:43 | <annevk> | this saves some templates on the server side, but is probably a nightmare for search engines and older clients... |
| 09:45 | <hsivonen> | I'm fine with certain things being left to the server side |
| 09:46 | <hsivonen> | server side means that all sites don't need to buy in to the same solutions and can be updated out of sync and can explore stuff without browser cooperation |
| 09:46 | <annevk> | maybe there are more convincing use cases |
| 09:47 | <hsivonen> | Hixie: are data templates *really* supposed to work inline or do you expect people to use XML templates by reference anyway? |
| 09:47 | <hsivonen> | I mean inline in text/html |
| 09:47 | <annevk> | I suppose it helps in the cases where you don't have a server, as in offline applications |
| 09:47 | <hsivonen> | I'm sensing some serious scope creep here |
| 09:48 | <annevk> | Although writing some JavaScript to do the same might not be too hard |
| 09:48 | <hsivonen> | I feel like sending a dozen emails, but I don't want to stir it on public-html up front |
| 09:48 | <annevk> | e-mail whatwg⊙wo ? |
| 09:49 | <annevk> | and say it's important as you're planning to implement |
| 09:49 | <hsivonen> | yeah, when I have smart questions to ask, I'll probably take the whatwg route |
| 09:54 | <jgraham> | FWIW I think Hyatt suggested the datatemplate thing |
| 09:54 | <zcorpan> | "Most mobile browsers do not support everything HTML defines. Our experience is that XHTML Basic delivered with application/xhtml+xml is more likely to result in a functional user experience than other combinations." -- http://lists.w3.org/Archives/Public/public-bpwg-comments/2007OctDec/0012.html |
| 09:57 | <annevk> | sounds like bs |
| 09:57 | <hsivonen> | I must be living in some parallel universe where I carry a Gecko-based browser, a WebKit-based browsers and three Opera-based browsers on my person when I go out |
| 09:57 | <annevk> | although maybe they can give some pointers to research they've done in that area, that counters yours |
| 09:58 | <annevk> | and even then WebKit would get the encoding wrong :p |
| 10:02 | <Philip`> | hsivonen: From what I've seen, inline text/html datatemplates appear to have extremely limited uses, since you can't use any interesting HTML elements in them without breaking in HTML5 UAs and in pre-HTML5 UAs |
| 10:05 | <hsivonen> | Philip`: if that's true, I don't like inline datatemplates |
| 10:15 | <annevk> | more on XUL templates: http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html |
| 10:17 | <Philip`> | (At least the <select><nest></select> is broken by HTML5 parsers in http://philip.html5.org/demos/datatemplate/experimental/002.html - not sure if there are other problems there) |
| 10:18 | annevk | would expect that the parsing rules are modified at some point |
| 10:18 | <annevk> | for <select> you can use a data= attribute btw that points to an external XML file |
| 10:18 | <annevk> | although then you'd have to do the templating on the server side |
| 10:19 | <Philip`> | If the contents of <datatemplate> doesn't get parsed like normal HTML, it'd seem even weirder to have it inline in HTML documents |
| 11:10 | annevk | didn't know you could specify 'Content-Type:text/html (this is a meaningless comment)' in HTTP |
| 11:10 | annevk | wonders if it actually works |
| 11:17 | <zcorpan> | annevk: seems to work in opera but not mozilla, testing with a data: uri |
| 11:18 | <zcorpan> | safari for windows crashed |
| 11:22 | <hsivonen> | comments in protocol don't make sense to me |
| 11:22 | <hsivonen> | it's not like humans are supposed to talk HTTP by hand and other humans supposed to read it |
| 11:23 | <annevk> | maybe for debugging purposes? |
| 11:23 | <annevk> | seems that the old specs are hopelessly out of data though |
| 11:23 | annevk | is reading through RFC2045 and 2046 |
| 11:24 | <annevk> | all subtypes of "text" must use CRLF as newline delimiter |
| 11:24 | <hsivonen> | annevk: well, to me it looks like comments are yet another thing to debug |
| 11:24 | <hsivonen> | haha |
| 11:24 | <annevk> | this is false for all text subtypes I know |
| 11:24 | <hsivonen> | yeah |
| 11:24 | <hsivonen> | except in email |
| 11:25 | <hsivonen> | CRLF is one of the worst ideas ever in text processing |
| 11:26 | annevk | was reading this because Hixie is defining a format that ignores RFC 2046 in two ways: it uses LF as newline delimiter and UTF-8 is the encoding |
| 11:27 | <zcorpan> | which format is that? |
| 11:29 | <annevk> | it's part of #offline for caching |
| 11:29 | <zcorpan> | the manifest thing? |
| 11:30 | <annevk> | yeah |
| 11:30 | <annevk> | hmm, the default media type in case Content-Type is bogus or absent is 'text/plain; charset=us-ascii' |
| 11:31 | <annevk> | (to be fair, all this is from 1996) |
| 11:34 | <virtuelv> | annevk: url for Hixie's spec? |
| 11:34 | <annevk> | it's part of HTML5 |
| 11:34 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/#offline |
| 11:35 | <annevk> | zcorpan, allowing comments in data: URIs types is a bug per the data URI specification it seems |
| 11:35 | <zcorpan> | annevk: ok |
| 11:36 | <annevk> | it defines mediatype itself as '[ type "/" subtype ] *( ";" parameter )' |
| 11:38 | <hsivonen> | HTTP matters so much more than SMTP for the transfer of novel types. |
| 11:38 | zcorpan | likes idea #3 better than the other two ideas |
| 11:39 | <hsivonen> | we should repeal the old MIME RFCs and write new specs that are sane for HTTP and have exceptions for the SMTP legacy |
| 11:39 | <zcorpan> | why can't the manifest have the mime type text/plain ? |
| 11:40 | <annevk> | so that text/plain does not have to be sniffed? |
| 11:41 | <annevk> | hsivonen, the problem is the amount of work |
| 11:41 | <zcorpan> | you'd only sniff it if it was referenced from <html application="...">, no? |
| 11:41 | <zcorpan> | s/sniff/process/ |
| 11:42 | <annevk> | hmm, maybe |
| 11:43 | <zcorpan> | just like e.g. a css style sheet doesn't do anything if you view it directly |
| 11:45 | <annevk> | i don't think I care much either way |
| 11:46 | <annevk> | using a MIME type is less likely to upset people though and doesn't cost much |
| 11:46 | <annevk> | and if it doesn't work out it can always be obsoleted |
| 11:47 | <zcorpan> | from a practical point of view -- what file extension will you use? does apache have a mapping for that file extension? |
| 11:47 | <zcorpan> | we might end up having authors use all of text/cache-manifest, text/plain and text/html etc |
| 11:48 | <zcorpan> | and browsers will have to support all of those or perhaps even ignore the content-type altogether |
| 11:48 | <zcorpan> | which seems worse than to just use text/plain |
| 11:49 | <annevk> | ignoring content-type information seems like an acceptable loss to me |
| 11:49 | <zcorpan> | ok, but what's the win of saying text/cache-manifest over text/plain? |
| 11:50 | <annevk> | it doesn't upset people who care about this, or upsets them less |
| 11:52 | <annevk> | (re: data URLs, they need to be updated too to be clear about fragment identifiers and that percent encoded URIs are always interpreted as UTF-8 (iirc)) |
| 11:53 | <zcorpan> | i don't see a difference here from xbl using application/xml instead of application/xbl+xml |
| 11:53 | <annevk> | all XML is processed the same way, text subtypes are process differently |
| 11:53 | <hsivonen> | FWIW, it suck rather badly for developers that application/json triggers download behavior (at least in Firefox) if you try to view directly |
| 11:53 | <annevk> | e.g. text/html vs text/css |
| 11:54 | <hsivonen> | sucks even |
| 11:54 | <annevk> | JSON doesn't need a Content-Type really... |
| 11:54 | <zcorpan> | annevk: the problem was that saying application/xbl+xml is likely to result in mislabeled content, and the same applies to text/cache-manifest |
| 11:54 | <hsivonen> | also, .rng and .rnc don't really benefit from non-text/plain content types |
| 11:55 | <hsivonen> | since people who view those types directly want to see them as text |
| 11:56 | <annevk> | zcorpan, that was not the only argument |
| 11:56 | <annevk> | but sure |
| 11:56 | annevk | doesn't care much |
| 11:58 | <hsivonen> | in general, it seems to me that only document formats (plain text, HTML, PDF, ODF, etc.) should have authoritative types |
| 11:58 | <hsivonen> | and style sheet, schemas, scripts, auxiliary data files, etc. would be better without |
| 11:59 | <hsivonen> | the test should be "Do end users who aren't debugging want to load this in the a browsing context?" |
| 11:59 | <hsivonen> | Yes => typed. No => untyped |
| 12:13 | <annevk> | btw, prompting for text/unknown is wrong in theory |
| 12:17 | <virtuelv> | Hm. I'd probably like to see the offline manifest as JSON instead |
| 12:17 | <annevk> | see #whatwg archives |
| 12:17 | <annevk> | JSON was too complex with too many edge cases |
| 12:18 | <virtuelv> | ok |
| 12:18 | <annevk> | XML even more so |
| 12:19 | <virtuelv> | goes without saying |
| 12:50 | <hsivonen> | what's matchAll() or getElementsBySelector() called today? |
| 12:50 | hsivonen | isn't following the naming debate anymore |
| 12:51 | <annevk> | querySelector() and querySelectorAll() |
| 12:52 | <hsivonen> | thanks |
| 13:08 | <hsivonen> | I thought JSON had Draconian failure on error without edge cases |
| 13:23 | <zcorpan> | is there a way to make non-html elements focusable? |
| 13:24 | <zcorpan> | html:role is pretty useless otherwise |
| 13:25 | <zcorpan> | unless we say e.g. that html:role makes the element focusable in and of itself |
| 13:28 | <annevk2> | SVG has focusable= |
| 14:37 | zcorpan | looks at svg mobile 1.2 |
| 14:37 | <zcorpan> | <circle cx="300" cy="225" r="100" fill="red"> |
| 14:37 | <zcorpan> | <handler type="application/ecmascript" ev:event="DOMActivate"> change(evt); </handler> |
| 14:37 | <zcorpan> | </circle> |
| 14:38 | <zcorpan> | what's wrong with <circle ... onclick="chance(event)"/> ? |
| 14:38 | <zcorpan> | s/chance/change/ |
| 14:39 | <zcorpan> | http://www.w3.org/TR/SVGMobile12/interact.html#UIEvents |
| 14:39 | <annevk2> | XML Events seemed like the way forward or something |
| 14:40 | <zcorpan> | seem just more verbose to me |
| 14:42 | <virtuelv> | zcorpan: I presume that someone foresaw a future where javascript was dead |
| 14:42 | <virtuelv> | <handler type="application/x-brainfuck" ev:event="DOMActivate"> change(evt); </handler> |
| 14:42 | <annevk2> | zcorpan, yes, formal objections to that effect have been raised and subsequently ignored iirc |
| 14:57 | <zcorpan> | right |
| 14:57 | <zcorpan> | still, Content-Script-Type could solve that the day another script type becomes evident |
| 14:58 | <zcorpan> | as specced in html4 ten years ago |
| 15:12 | <annevk2> | I wonder how many servers have bogus values for that header |
| 15:12 | <annevk2> | and for the style equivalent header for that matter |
| 15:15 | <zcorpan> | i've seen the headers in the wild but not with bogus values |
| 15:16 | <zcorpan> | i think some versions of firefox respect them |
| 17:24 | <Hixie> | hsivonen: i'll be online in about 2 hours and can reply to any datatemplate questions |
| 17:25 | <Hixie> | hsivonen: in brief: not expected to be used inline in html; didn't expect machine checkable to actually apply the templates |
| 17:25 | <Hixie> | hsivonen: did expect validators to at least check that there was one context in which all the children of the <rule> element could theoretically be valid together |
| 17:26 | <Hixie> | hsivonen: datatemplate is basically expected to replace the repetition construct stuff; i'm not convinced that repetition blocks are easier, i actually think datatemplates are easier |
| 17:27 | <Hixie> | zcorpan: text/plain isn't a manifest. while we're pretending that content-type still exists, we should at least try to honour its concepts |
| 17:28 | <zcorpan> | Hixie: ok. i don't expect it to actually work though |
| 19:04 | <annevk2> | got to love that the XHTML2 WG is public now: "there is actual money value in efficiency boost by using XML and namespacing; tag soup devalues and compromises accessibility" |
| 19:05 | <annevk2> | also, "GJR: XBL draft dangersously underspecified" |
| 19:06 | <zcorpan> | annevk2: pointers? |
| 19:06 | <annevk2> | http://www.w3.org/2007/10/03-xhtml-minutes.html#item03 |
| 19:07 | <annevk2> | there's also some stuff about the non-namespaced role= solution not being forward-looking |
| 19:09 | <zcorpan> | ah, they discussed aria |
| 19:09 | zcorpan | reads |
| 19:14 | <Hixie> | zcorpan: well, the spec currently says to bail if the mime type doesn't match. but we'll see. :-) |
| 19:17 | <zcorpan> | Hixie: yep :) |
| 19:18 | <Hixie> | "XBL draft dangersously underspecified"? |
| 19:18 | <Hixie> | who's GJR? i should ask him for feedback |
| 19:18 | <annevk> | It's Gregory |
| 19:18 | <Hixie> | aha, gregory |
| 19:19 | <annevk> | pm'd you contact info in case you don't have it |
| 19:20 | <zcorpan> | i can't extract actual feedback on the aria proposal form the minutes |
| 19:21 | <Hixie> | hey dreamhost fixed my jabber problem at last |
| 19:24 | <annevk> | Hixie, maybe you could add examples to <datatemplate> that illustrate how it replaces repetition templates and such? |
| 19:25 | <Hixie> | man, have you seen these minutes? http://www.w3.org/2007/10/03-xhtml-minutes.html#item02 |
| 19:25 | <Hixie> | "WG decided to declare victory -- text/html is the media type, that's that -- then we thought better of it and switched it back" |
| 19:25 | <Hixie> | there are so many things wrong with that... i don't know where to start |
| 19:25 | <Hixie> | annevk: yeah, i need to fill in the intro section |
| 19:29 | <Hixie> | right. asked him for feedback. hopefully he can send me links to the underspecified parts, so i can fix them. |
| 19:30 | <annevk> | oh lol, role= will depend on CURIEs |
| 19:30 | <Hixie> | what's a curie again? i thought it was a unit of radiation. |
| 19:31 | <annevk> | per the XHTML2 WG it's an abbreviation of URIs |
| 19:31 | <Hixie> | ah |
| 19:31 | <gavin_> | abbreviations aren't usually longer than the word they're abbreviating |
| 19:31 | <annevk> | foo:bar expands into http://example.org/#bar if foo is bound to http://example.org/# |
| 19:32 | <Hixie> | ah so it's a qualified name? |
| 19:32 | <zcorpan> | no |
| 19:32 | <annevk> | qualified names don't expand into URIs |
| 19:32 | <annevk> | they expand into a namespace local-name tuple |
| 19:33 | <Hixie> | {http://www.example.org/#, bar} and http://example.org/#bar seem the same to me, except for some syntactic details |
| 19:34 | <annevk> | it's also that bar in this example is no longer restricted to a being a NCName |
| 19:35 | <annevk> | seems quite trivial these days to register MIME types btw |
| 19:36 | <Hixie> | lordy, whatwg seems to be taking up the slack now that public-html has stopped being high-traffic |
| 19:37 | <annevk> | e-mail on the whatwg list or something else? |
| 19:37 | <Hixie> | yes |
| 19:39 | <annevk> | hmm, which e-mail? |
| 19:39 | <Hixie> | i just mean that as traffic to public-html has gone down, traffic to whatwg has gone up |
| 19:40 | <annevk> | oh |
| 19:40 | <Hixie> | hsivonen: re how do we avoid <datatemplate> turning into a programming language: i think we'll define escaping to JS in the first version. i'm just not sure what the syntax should be yet. |
| 20:13 | <Hixie> | ah, apparently gregory didn't mean what he minuted about xbl |
| 21:57 | annevk | addresses some comments from Hixie on access-control |
| 22:16 | <Hixie> | annevk: changing the port defaults, or the other one? |
| 22:20 | <annevk> | the other |
| 22:20 | <annevk> | I tend to agree with port defaults, but I'd like to wait for the Mozilla folks to give feedback first |
| 22:21 | <annevk> | based on their feedback it's like it's now |
| 22:21 | <Hixie> | k |
| 22:21 | <Hixie> | (i guarentee that it will lead to security holes if we don't fix it, but i agree that we should consult with the browser vendors) |
| 22:22 | <annevk> | mozilla unfixed it :) |
| 22:22 | <annevk> | maybe we should just have a wildcard for port |
| 22:22 | <annevk> | http://example.org:* |
| 22:23 | <Hixie> | seems better than defaulting wild, yeah |
| 22:23 | <annevk> | the 99% case will likely be just <*> though |
| 22:24 | <Hixie> | no |
| 22:24 | <Hixie> | the 99% case will be 80. |
| 22:24 | <Hixie> | in only very few cases would you do it to anything but 80 |
| 22:24 | <Hixie> | almost all cases where you talk to a non-80 port, there'll be something fishy going on |
| 22:24 | <annevk> | if you bring this back to use cases, fair enough |
| 22:25 | <Hixie> | the security issue is pretty drastic |
| 22:25 | <Hixie> | you yourself are vulnerable |
| 22:25 | <Hixie> | philip` could impersonate zcorpan on html5.org, for example (assuming they both have separate use accounts to the same machine) |
| 22:26 | <Hixie> | if you and i were hosted on the same shared dreamhost machine, i could trivially run a web host at annevankesteren.nl:9999 |
| 22:26 | <annevk> | yeah, I understood that from your e-mail |
| 22:26 | <annevk> | quite annoying |
| 22:27 | <Hixie> | no argument from me there |
| 22:27 | <annevk> | what I've heard from others and what seems likely though is that the most common case will be <*> |
| 22:27 | <Hixie> | why? |
| 22:28 | Hixie | only very rarely seens non-80 HTTP traffic |
| 22:28 | <Hixie> | sees |
| 22:28 | <annevk> | no, I mean Access-Control: allow <*> |
| 22:29 | <Hixie> | ah |
| 22:29 | <Hixie> | yeah, that case should still have wildcard port |
| 22:29 | <Hixie> | and yeah, it'll be quite common |
| 22:29 | <annevk> | the <example.org> case will have wildcard as well right? |
| 22:29 | <annevk> | or do we want that to be a shorthand for http://example.org:80 |
| 22:30 | <Hixie> | if you don't have a scheme, you'd have to make it wildcard, i'd guess |
| 22:30 | <Hixie> | unless you default the scheme, but that seems bad |
| 22:30 | <annevk> | requiring authors to type <*://example.org:*> or something like that... |
| 22:30 | <Hixie> | if the scheme is "*" then i think defaulting the port to "*" would be fine |
| 22:30 | <Hixie> | really all i'm saying is that "http" implies a port, so when you have that port implication, it shouldn't default to wild |
| 22:31 | <annevk> | i guess that's fair enough |
| 22:43 | <annevk> | Hixie, btw, is it really that dangerous? as this is mostly to protect information leakage from the intranet, after all |
| 22:44 | <annevk> | maybe I'm missing something |
| 22:46 | <Hixie> | yes |
| 22:47 | <Hixie> | let http://example.com/ be user-authentication (by cookie or http) and let it host some user-sensitive data |
| 22:47 | <Hixie> | user-authenticated, that is |
| 22:48 | <Hixie> | let http://affiliate.invalid/ be a separate organisation that has an agreement with example.com to use the user-sensitive data |
| 22:48 | <Hixie> | example.com's data is only accessible to UAs that are logged in to example.com, and to scripts running in example.com's domain and affiliate.invalid's domain. |
| 22:49 | <Hixie> | now let http://evil.example.net/ be an unrelated evil organisation that happens to be hosted on the same IP as affiliate.invalid |
| 22:49 | <Hixie> | the http://evil.example.net/ organisation can host content at http://affiliate.invalid:9999/ that can now access http://example.com/'s data when a user is sent to http://affiliate.invalid:9999/ (e.g. by phishing) |
| 22:49 | <Hixie> | btw, this is the kind of thing that the security section should be discussing in detail |
| 22:50 | <Hixie> | and is why security sections are important |
| 22:50 | <annevk> | so the problem is that it's unclear whether authentication and cookies are actually supported |
| 22:50 | <annevk> | to me, anyway |
| 22:51 | <Hixie> | how do you mean? |
| 22:51 | <annevk> | cookies don't go in outgoing requests iirc and you can't specify user/password either |
| 22:52 | <Hixie> | the user is already logged in |
| 22:52 | <Hixie> | i don't understand what you mean |
| 22:52 | <Hixie> | cookies had better be sent to the server, how else can we do user authentication? |
| 22:53 | <annevk> | I think that's prevented, but maybe the only prevention is about reading those cookies in the response |
| 22:53 | <Hixie> | i hope so |
| 22:53 | <Hixie> | otherwise i have a whole bunch more comments to send :-) |
| 22:53 | annevk | summons sicking |
| 22:54 | <Hixie> | the spec says cookies should work (xhr2) |
| 22:54 | <annevk> | it also says it doesn't deal with some things yet |
| 22:54 | <annevk> | this being one of them :) |
| 22:54 | <Hixie> | it does deal with it, it explicitly says it should work :-) |
| 22:54 | <Hixie> | "If the user agent supports HTTP State Management it should persist, discard and send cookies (as received in the Set-Cookie and Set-Cookie2 response headers, and sent in the Cookie header) as applicable. [RFC2965]" |
| 22:55 | <annevk> | fair enough, though not what I meant |
| 22:55 | <Hixie> | what did you mean then? |
| 22:55 | <annevk> | there's a note somewhere on limiting stuff on requests |
| 22:55 | <annevk> | issue, rather |
| 22:56 | <annevk> | such as setted request headers |
| 22:56 | <annevk> | and there was something about user/password too |
| 22:56 | <annevk> | i'll e-mail jonas |
| 22:56 | <Hixie> | you mean in addRequestHeader? |
| 22:56 | <annevk> | set*, yes |
| 22:56 | <Hixie> | right setRequestHeader() certainly shouldn't let cookies be set for cross-origin hosts |
| 22:56 | <Hixie> | i'm talking about the cookies that the UA already has set |
| 22:57 | <Hixie> | (allowing setRequestHeader() to set cookies would allow for a distributed cookie search attack) |
| 23:00 | <annevk> | thanks, this helps clearing some stuff up |
| 23:01 | <Hixie> | np |
| 23:06 | <sicking> | wassup |
| 23:06 | <annevk> | heh |
| 23:07 | <annevk> | just e-mailed |
| 23:07 | gavin_ | relayed annevk's summoning |
| 23:07 | <annevk> | cheers |
| 23:07 | <annevk> | basically, what's the XHR2 model for non-same origin requests with respect to the user/password arguments of open() and what is with respect to cookies |
| 23:08 | annevk | wonders if gavin_ summoned the entire #developer channel |
| 23:08 | <gavin_> | well, I relayed it publically :) |
| 23:08 | <sicking> | annevk: we don't allow user/passwd to be specified for cross-origin requests |
| 23:08 | <gavin_> | biesi must just be curious :) |
| 23:09 | <annevk> | sicking, ignored or exception? |
| 23:09 | <sicking> | annevk: why did you respond to hixie on the webapi list btw? |
| 23:09 | <annevk> | oops |
| 23:09 | <sicking> | annevk: leeme look |
| 23:09 | <sicking> | lemme even |
| 23:10 | <biesi> | gavin_, yep :) |
| 23:10 | annevk | resends to public-appformats |
| 23:11 | <Hixie> | did i send it to the wrong list? |
| 23:11 | <annevk> | don't think so |
| 23:11 | <sicking> | no, anne did |
| 23:12 | Hixie | has now defined the syntax of manifests, btw (http://www.whatwg.org/specs/web-apps/current-work/#manifests) |
| 23:13 | annevk | loads |
| 23:13 | <annevk> | "Note: This is a willful double violation of RFC2046." |
| 23:13 | <annevk> | heh |
| 23:13 | <kingryan> | two wrongs make a right? |
| 23:13 | <annevk> | Hixie, is the UTF-8 thingie a violation too? Where is that stated? |
| 23:13 | <Hixie> | *mumble* stupid rfc |
| 23:14 | <annevk> | it's from 1996... |
| 23:14 | <Hixie> | annevk: RFC2046 requires the default to be us-ascii (HTTP changes it to ISO-8859-1) and RFC2046 requires newlines to be CRLF (HTTP changes that to CR, LF, or CRLF) |
| 23:14 | <Hixie> | (but HTTP requires that they be consistent throughout the file) |
| 23:14 | <annevk> | so per HTTP you violate only a single rule |
| 23:14 | <Hixie> | (html5 changes it to UTF-8 and CR|LF|CRLF) |
| 23:15 | <annevk> | oh wait |
| 23:15 | <annevk> | you changed the sole LF requirement |
| 23:15 | <annevk> | interesting |
| 23:15 | <Hixie> | yeah otherwise windows users would hit me |
| 23:15 | <Hixie> | bbiab |
| 23:15 | <annevk> | Hixie, should it mention the UTF-8 BOM? |
| 23:15 | <Hixie> | mtg |
| 23:17 | <sayrer> | annevk, is the manifest format already in use somewhere? |
| 23:17 | <jgraham> | Hixie: Is there a good reason not to allow comments on data lines? |
| 23:17 | <jgraham> | At the end obviously |
| 23:17 | <annevk> | sayrer, nope |
| 23:18 | <biesi> | Hixie, HTTP specifies what the actual data must contains? |
| 23:18 | <annevk> | sayrer, just that editors might include such a thing by default |
| 23:18 | <biesi> | s/s\?/?/ |
| 23:19 | <annevk> | Hixie, you want s/<li>/<dt>/ there somewhere |
| 23:20 | <sayrer> | [{explicit:[,,,]},{fallback:[],,]}] |
| 23:20 | <sayrer> | would avoid parsing and encoding issues |
| 23:21 | <annevk> | sayrer, http://krijnhoetmer.nl/irc-logs/whatwg/20070929#l-17 |
| 23:23 | <sayrer> | oh, most JSON parsers grok comments |
| 23:24 | <sayrer> | but yeah, it's all a bit gross |
| 23:24 | <Philip`> | That sounds like a flaw, not a feature :-) |
| 23:24 | <sayrer> | it's actually right there in the JSON rfc |
| 23:24 | <sayrer> | you can accept more than is allowed |
| 23:25 | <annevk> | fun |
| 23:25 | <sayrer> | so lots of them deal with comments, unquoted keys, trailing commas |
| 23:25 | <annevk> | "A JSON parser MAY accept non-JSON forms or extensions." |
| 23:25 | <annevk> | anyone up for writing JSON5? |
| 23:26 | jgraham | was wondering how long that would take to be suggested |
| 23:26 | <Philip`> | s/MAY/MUST NOT/ and then the world will be a happier place |
| 23:26 | <jgraham> | JSON5 = JSON + comments - arbitrary extendibility |
| 23:27 | <annevk> | it's funny that JSON defaults to UTF-8 and wants to be a subset of JavaScript; but maybe I'm just being to anal |
| 23:27 | <kingryan> | jgraham: http://krijnhoetmer.nl/irc-logs/whatwg/20070929#l-53 |
| 23:28 | <annevk> | oh fun, it even allows UTF-32 |
| 23:28 | <annevk> | hsivonen will be pleased |
| 23:30 | <sayrer> | anyway, I'm now convinced there is no good choice |
| 23:31 | <annevk> | "Whenever I'm caught between two evils, I take the one I've never tried." |
| 23:33 | <annevk> | sicking, found out whether you guys throw or not? |
| 23:33 | <sicking> | looking |
| 23:34 | <sicking> | sorry, got sidetracked |
| 23:34 | <Hixie> | annevk: hm, BOM, good point. |
| 23:34 | <Hixie> | jgraham: not especially, other than making parsing easier. do you think it should support that? |
| 23:35 | <sicking> | annevk: we throw if you specify a cross-origin uri and user/pass |
| 23:36 | <annevk> | sicking, what's the reason it's not allowed, might be useful for security section |
| 23:36 | <sicking> | annevk: on a redirect we'll fire an error-event |
| 23:36 | <jgraham> | Hixie: it seems like a low cost thing that people might find useful and will probably expect to work |
| 23:36 | <sicking> | annevk: otherwise it would be easy to do distributed brute-force hacking of an account |
| 23:36 | <sicking> | annevk: for some definition of "easy" :) |
| 23:37 | <Hixie> | sayrer: yeah the problem with JSON is that it doesn't have well defined error handling |
| 23:37 | <annevk> | k, but if the user is already logged in you have access I assume? |
| 23:37 | <annevk> | Hixie, I wonder if you just shouldn't allow arbitrary encodings and defualt to UTF-8 respecting charset= and all that |
| 23:38 | <sayrer> | Hixe, might want to reconsider that comment character if you allow it on data lines |
| 23:38 | <sicking> | annevk: basically i could set up a page and everyone that visited that page would take part in a distributed dictionary attack |
| 23:38 | <Hixie> | jgraham: fair enough |
| 23:38 | <sayrer> | since you know people will end up with fragment identifiers in these things |
| 23:39 | <sicking> | annevk: yeah, if the user is logged in already it should work |
| 23:39 | <Hixie> | annevk: i'd really rather not bring in all the legacy encodings into this |
| 23:39 | <annevk> | sicking, k, what about cookies? |
| 23:39 | <sicking> | annevk: over the network they are sent as per usual |
| 23:39 | <annevk> | Hixie, given everything else that's required for the feature it seems low-cost, but fair enough |
| 23:39 | Hixie | notes that was sicking just described is exactly what Hixie described earlier as the problem with sending cookies -- it's the same issue |
| 23:39 | <sicking> | annevk: but accessing document.cookies on the returned document fails |
| 23:40 | <sicking> | Hixie: how so? |
| 23:40 | <Hixie> | annevk: encodings are a near-infinite pit of doom, in my experience |
| 23:40 | <Hixie> | sicking: (i was agreeing with you) |
| 23:40 | <sicking> | Hixie: ah |
| 23:40 | <Hixie> | sicking: i was saying that setRequestHeader() shouldn't allow Set-Cookie because it would enable a distributed brute-force cookie search |
| 23:40 | <sicking> | Hixie: well, iirc i'm agreeing with you. i think the idea came from you at the xxx security review here at moco |
| 23:40 | <Hixie> | heh |
| 23:40 | <Hixie> | figures :-) |
| 23:41 | Hixie | hopes he isn't the only person to have come up with security problems with xhr :-P |
| 23:41 | <Hixie> | cos i'm by far not a security expert! |
| 23:42 | <sicking> | annevk: we basically do this: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 |
| 23:43 | <annevk> | oh, if you guys implement the XMLHttpRequest-Security-Check header that can simply be renamed to If-Method-Allowed... |
| 23:44 | <annevk> | but I think you didn't |
| 23:44 | <Hixie> | where does If-Method-Allowed come from? |
| 23:44 | <annevk> | generic name for XHR-Security-Check |
| 23:44 | <Hixie> | oh it's invented as well? |
| 23:45 | <annevk> | yes |
| 23:45 | <annevk> | i have tried to clarify this by making up some EBNF in the spec... |
| 23:46 | <Hixie> | k |
| 23:46 | <Hixie> | it sounds nice and official |
| 23:46 | <annevk> | good |
| 23:47 | <othermaciej> | that does sound like a good name |
| 23:48 | <Hixie> | it doesn't really follow the semantics of the other If-XXX headers though |
| 23:49 | <annevk> | If-Allow-Method maybe? |
| 23:49 | <annevk> | or just If-Allow... |
| 23:49 | <Hixie> | the If-XXX headers have the semantic "do what i say if the condition matches, else return 412" |
| 23:50 | <othermaciej> | what would If-Method-Allowed do if the method is not allowed? |
| 23:51 | <annevk> | it does nothing, it just lets the author of the server inspect what the user agent intends to do |
| 23:51 | <Hixie> | the question is more what it would do if the method _was_ allowed |
| 23:51 | <Hixie> | well |
| 23:51 | <annevk> | the author replies with Allow:GET,HEAD,FOOBAR |
| 23:52 | <Hixie> | right which isn't the same semantic as the other If-XXX headers |
| 23:52 | <annevk> | afaict it's not implemented so renaming is certainly possible |
| 23:53 | <Hixie> | maybe Is-Method-Allowed? |
| 23:53 | <Hixie> | or Query-Is-Method-Allowed? |
| 23:53 | <Hixie> | (assuming you don't want XMLHttpRequest-Security-Check, which i think has the advantage of being very clear as to its purpose :-) ) |
| 23:53 | Hixie | doesn't really mind what it's called |
| 23:53 | <annevk> | Method-Security-Check |
| 23:54 | <annevk> | or just Method-Check |
| 23:54 | <annevk> | Referer-Root doesn't have Security in it either |
| 23:54 | <Hixie> | if we do have a more generic name, though, we should define its processing semantics even when not in the context of xhr |
| 23:54 | <Hixie> | it was more the "XMLHttpRequest" part I was referring to |
| 23:55 | <Hixie> | Referer-Root doesn't have any processing semantics other than letting the server know what's going on, which makes it easy to make generic |
| 23:55 | <Hixie> | (and it's only useful when Referer: isn't set anyway) |
| 23:55 | <annevk> | same goes for Method-Check, no? |
| 23:55 | <Hixie> | no, Method-Check has a very specific set of requirements to do with what the server responds with |
| 23:55 | <Hixie> | e.g. as you said earlier, the Allow: thing |
| 23:56 | <annevk> | seems more like requirements on the Allow:, not on Method-Check |
| 23:56 | <Hixie> | ? |
| 23:56 | <annevk> | Allow or absense thereof* |
| 23:56 | <Hixie> | Allow: is what it sends in response to Method-Check |
| 23:57 | <Hixie> | thus the requirement is on Method-Check |
| 23:57 | <annevk> | you mean it follows from the request that includes Method-Check? |
| 23:58 | <Hixie> | right |
| 23:58 | <annevk> | (btw, what do you think of jonas proposal about defaulting to the referer-root URI scheme default port?) |
| 23:58 | <sicking> | i think it's an excellent suggestion |
| 23:58 | <sicking> | cookies to whoever suggested that! |
| 23:59 | <annevk> | :p |
| 23:59 | <annevk> | Hixie, hmm, yeah, the current text in access-control is rather vague on Allow |
| 23:59 | <sicking> | annevk: for example, should it be case sensitive or not? |