/irc-logs / freenode / #whatwg / 2007-11-19 / end

Options:

  1. # Session Start: Mon Nov 19 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  4. # [00:01] * Quits: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Read error: 104 (Connection reset by peer))
  5. # [00:02] * Joins: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  6. # [00:11] <Philip`> 3D is too hard :-(
  7. # [00:21] * Joins: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no)
  8. # [00:23] * weinig is now known as weinig|food
  9. # [00:23] * Quits: Lachy (n=Lachlan@ti200710a340-2585.bb.online.no) (Read error: 104 (Connection reset by peer))
  10. # [00:57] * Quits: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no) ("This computer has gone to sleep")
  11. # [00:58] * Quits: tndH (i=Rob@87.102.22.166) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  12. # [01:15] <othermaciej> does anyone know if XAML has a an immediate-mode graphics API>
  13. # [01:15] <othermaciej> ?
  14. # [01:29] <alp> othermaciej: xaml is just the markup, but afaik wpf is entirely retained mode
  15. # [01:30] <othermaciej> looks like it to me too, so far as I can tell from the docs
  16. # [01:32] * othermaciej wonders how custom classes do their drawing
  17. # [01:34] <othermaciej> aha, there is direct rendering
  18. # [01:34] <othermaciej> via OnRender
  19. # [01:35] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) ("Lost terminal")
  20. # [01:36] <alp> is the consensus on geolocation currently use navigator.getGeolocation()? i'm going to hack up support for this in the n810 tablet browser
  21. # [01:37] <othermaciej> no idea
  22. # [01:37] <alp> maybe someone who was involved in this thread knows, http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009626.html
  23. # [01:38] <othermaciej> I don't know if anyone implements it, might be worth asking Opera and/or Nokia folks
  24. # [01:39] * Joins: tantek (n=tantek@99-200-206-102.area2.spcsdns.net)
  25. # [01:43] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  26. # [02:06] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  27. # [02:10] * Quits: grimeboy (n=grimboy@85.211.237.68) (Read error: 110 (Connection timed out))
  28. # [02:17] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  29. # [02:27] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  30. # [03:27] <jruderman> Hixie: have you been following the discussions in m.d.a.firefox about <a ping>?
  31. # [03:27] <jruderman> Hixie: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/a8469770c8f9fe52
  32. # [03:46] <Hixie> i was aware of the discussion but haven't followed it
  33. # [03:46] <Hixie> anything i should be aware of?
  34. # [03:56] <roc> "UI for pings sucks"
  35. # [04:01] <othermaciej> you could do a status bar effect, that would be sufficient for the sort of person likely to be a privacy weenie and unobstrusive otherwise
  36. # [04:01] <othermaciej> that's what I would do if I wanted to implement ping
  37. # [04:02] <othermaciej> (if you have the status bar off, or don't look, you don't even know where the link will go, so why would you care that it pings an extra URL?)
  38. # [04:07] <Hixie> yeah i didn't understand the arguments against the status bar thing
  39. # [04:07] <Hixie> i don't see how it sucks any more than the link UI in the first place
  40. # [04:10] <othermaciej> I did not read the arguments in detail, that's just my immediate thought
  41. # [04:10] <roc> a privacy weenie might as well just disable ping altogether
  42. # [04:11] <roc> maybe the sort of person exists who obsessively checks the status bar every time they click on a link
  43. # [04:11] <roc> I'd like to see an existence proof before implementing UI for them
  44. # [04:11] <roc> (and in Firefox of course they could have their own special extension)
  45. # [04:12] <othermaciej> my conclusion is mostly that "ping" is not useful enough to implement
  46. # [04:12] <othermaciej> the main benefit is that it potentially gives users more info
  47. # [04:12] <othermaciej> but most users won't care
  48. # [04:13] <othermaciej> roc: I tend to look at the status bar before clicking blog links, though out of curiosity more than anything
  49. # [04:13] <othermaciej> I don't always look though
  50. # [04:13] * Joins: gavins (n=gavin@firefox/developer/gavin)
  51. # [04:14] * gavins is now known as gavin_
  52. # [04:15] <othermaciej> I guess <a ping> has the side effect that if sites use it, you get to see the real target URL in mouseover feedback
  53. # [04:15] <othermaciej> not the tracking redirect URL
  54. # [04:16] <othermaciej> the question is whether any sites will use it
  55. # [04:16] <roc> I think it's useful to implement. a) it's supposed to yield faster navigation than going through a redirect, b) you get the real URL on "copy link location" instead of some redirect URL, c) if sites start using it then people can disable it to get privacy benefits
  56. # [04:17] <othermaciej> I think all of those are contingent on "if sites start using it"
  57. # [04:17] <roc> most features are :-)
  58. # [04:17] <othermaciej> the more people disable it, the less sites are inclined to use it
  59. # [04:17] <othermaciej> well, some can give significant benefits only if relatively few sites use it
  60. # [04:18] <roc> if we ship it enabled, almost no-one will disable it
  61. # [04:18] <othermaciej> but certainly every feature should consider transition costs to using it
  62. # [04:18] <jwalden> get Google to promise to use it, and maybe I'd go for it
  63. # [04:18] <othermaciej> some sites get upset that Firefox lets you do ad blocking through extensions (not even the default UI)
  64. # [04:18] <othermaciej> some sites have crazy counter-measures for pop-up blocking even though it is not on by default for the majority of browser users
  65. # [04:18] <roc> yes, well, some sites are run by morons
  66. # [04:18] <jwalden> (instead of their current sucky redirect-URL-that-you-can-copy approach)
  67. # [04:19] <othermaciej> and "ping" has no story for fallback in browsers that don't support it
  68. # [04:19] <othermaciej> unlike things like <canvas> and <video>
  69. # [04:19] <roc> I "heard" that major search sites are keen on using <ping> because of the usability speedup from cutting the redirect out of the equation
  70. # [04:20] <othermaciej> for ad links?
  71. # [04:20] <roc> the fallback story for <canvas> and <video> is in reality quite weak.
  72. # [04:20] <jwalden> tangible benefits for the user are the only way to sell it -- that's the one I see working
  73. # [04:20] <othermaciej> I doubt search engines would use it for ad links, since then they would undercount the number of ad hits
  74. # [04:20] <othermaciej> which loses them money
  75. # [04:20] <roc> I think the idea was to track which search results users click on
  76. # [04:20] <othermaciej> (until most browsers support it, they would *vastly* undercut the number of ad hits)
  77. # [04:21] <othermaciej> ah
  78. # [04:22] <jwalden> depends how cheap user-agent-specific behavior is -- probably pretty cheap
  79. # [04:23] <othermaciej> might be useful for cases where lossy data is acceptable
  80. # [04:23] <othermaciej> anyway, I think either no UI or status bar indicator would be a reasonable form of the feature
  81. # [04:24] <othermaciej> I would lean towards status indicator since you lose the ability to see that the URL is some weird redirect thing with <a ping> but I don't think that is a very strong argument
  82. # [04:25] * weinig|food is now known as weinig
  83. # [04:25] <roc> I think sites have to care enough to UA-sniff. Hopefully some will. We'll have to ship it and hope, like a lot of other things we've done
  84. # [04:25] <othermaciej> I specifically don't think the UI for ping needs to be any better than the UI for seeing where a link will go before clicking it
  85. # [04:25] <othermaciej> <video> could be used without UA-sniffing
  86. # [04:25] <othermaciej> and UA-sniffing is a bad practice
  87. # [04:26] <othermaciej> any fallback story that depends on UA sniffing is weak
  88. # [04:27] <roc> got a better idea for this situation?
  89. # [04:27] <roc> maybe standardize a redirect URL format and have "ping" automatically re-directize the URL :-)
  90. # [04:27] <roc> er
  91. # [04:27] <roc> un-redirectize
  92. # [04:37] <jwalden> redirect://site.com/redirector?http://url-to-visit/
  93. # [04:37] <jwalden> so basically feed: all over again
  94. # [04:38] <roc> no
  95. # [04:38] <jwalden> er
  96. # [04:38] <jwalden> yeah, that's wrong
  97. # [04:38] <jwalden> blah, this hurts my head
  98. # [04:40] <roc> more like <a ping="pings.example.com" href="http://pings.example.com/redirect?http://mozilla.org"> and we guarantee that "ping", if supported, will strip off everything up to and including the first ?
  99. # [04:40] <roc> well, that's kinda wrong but that's the idea
  100. # [04:40] <roc> but that's actually a stupid idea
  101. # [04:40] <roc> so never mind
  102. # [04:42] <othermaciej> roc: ah, interesting
  103. # [04:43] <othermaciej> roc: that certainly has better fallback behavior, though still not sure that would drive more adoption
  104. # [04:43] <othermaciej> this is really a case where we need to ask content authors who do tracking what they think
  105. # [04:45] <roc> my understanding is that this was driven by content authors
  106. # [04:46] <roc> the problem with my idea is that it leaves the HREF busted
  107. # [04:46] <roc> for "Copy Link Location" etc
  108. # [04:47] <roc> oh, I suppose that for "ping"-supporting browsers, Copy Link Location and other UI features could auto-strip the URL
  109. # [04:47] <roc> as well
  110. # [04:48] <roc> adds complexity :-(
  111. # [04:59] <Hixie> yeah ping="" was basically designed by google to handle the problems that google has with the currently available options (and believe me, google is an _expert_ at how to do this kind of stuff)
  112. # [05:01] <Hixie> the biggest problems with that state of the art, from google's point of view, are lack of user privacy options (disabling), redirect slowness (which can be avoided with some browsers by abusing some bugs, but that sucks), and the transparency issue
  113. # [05:16] * Joins: MikeSmith (n=MikeSmit@eM60-254-229-77.pool.emnet.ne.jp)
  114. # [05:36] <jruderman> i hadn't thought of the "which search results did the user click?" use case, but it makes a lot of sense, given that google has been trying to do that for a while (presumably to improve search results rather than for any nefarious purpose)
  115. # [05:38] <jruderman> Hixie: i thought beltzner's posts in that thread were especially good
  116. # [05:38] <jruderman> Hixie: do you have a suggestion for what the enable-ping checkbox label should be? :)
  117. # [05:40] <Hixie> what did beltzner propose?
  118. # [05:40] <Hixie> [x] Allow sites to track which links you click on
  119. # [05:41] <roc> the problem with that is that even when you clear it, sites can still track which links you click on
  120. # [05:43] <Hixie> sites can still animate images even when animated images are disabled
  121. # [05:43] <Hixie> so what?
  122. # [05:43] <roc> this is true
  123. # [05:44] <roc> but we don't seem to have that pref in Firefox anymore :-)
  124. # [05:45] <roc> so I guess you need to think of another example
  125. # [05:45] <Hixie> cookies and flash
  126. # [05:46] <Hixie> but my point is just that the pref doesn't have to be pedantically correcty
  127. # [05:46] <Hixie> correct, even
  128. # [05:46] <roc> I guess the problem is that it's not even close
  129. # [05:46] <Hixie> it's close enough
  130. # [05:46] <roc> since at least initially clicking that box will have no effect on anything
  131. # [05:47] <Hixie> [ ] Enable out-of-band declarative link tracking
  132. # [05:47] <Hixie> s/link/click/
  133. # [05:48] <Hixie> but personally i think "Allow sites to track which links you click on" is fine
  134. # [05:48] <roc> [ ] I trust Google
  135. # [05:48] <Hixie> or that
  136. # [05:48] <Hixie> though actually that's more misleading, imho
  137. # [05:49] <roc> I was joking, sorry
  138. # [05:49] <Hixie> since if you didn't trust google to use the track data ethically, you wouldn't trust google to use ping= in the first place
  139. # [05:49] <Hixie> oh i know :-)
  140. # [05:49] <Hixie> but even as a joke i don't think it works :-)
  141. # [05:50] * Quits: roc (n=roc@202.180.114.137)
  142. # [05:59] * Quits: tantek (n=tantek@99-200-206-102.area2.spcsdns.net)
  143. # [06:14] <jwalden> [ ] Whatever
  144. # [06:14] <jwalden> none of the proposed phrasings are clear enough to work without needing to refer to help documentation
  145. # [06:20] <othermaciej> "Allow sites to track which links you click on" seems reasonable, although it makes the feature sound scarier than it is
  146. # [06:29] * Quits: doublec (n=doublec@202.180.114.137)
  147. # [06:59] * Joins: kfish (n=conrad@61.194.21.25)
  148. # [07:36] <mpt> s/Allow (.+) to (.+)/Let \1 \2/g
  149. # [07:37] <mpt> But it still fails the "...or what?" test
  150. # [07:37] <mpt> i.e. you can't tell, by reading it, why you'd want to check it
  151. # [07:38] <mpt> (or uncheck it)
  152. # [07:38] * Joins: doublec (n=doublec@203-211-86-55.ue.woosh.co.nz)
  153. # [07:45] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  154. # [07:46] <Hixie> mpt: how would you phrase it?
  155. # [07:54] <jwalden> accuracy, clarity, non-tinfoil-hat-inducing -- pick two
  156. # [07:54] <jwalden> actually, make that second understandability
  157. # [07:58] <Hixie> to be honest i would target the pref at the tinfoil induced
  158. # [07:58] <Hixie> they're the only ones who will really care, based on my experience
  159. # [07:58] <Hixie> for all the cries about privacy -- and i agree that privacy is important -- few users seem to actually care in practice
  160. # [07:59] <Hixie> it's those who do care who should be able to turn it off easily
  161. # [08:02] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  162. # [08:06] * Quits: doublec (n=doublec@203-211-86-55.ue.woosh.co.nz)
  163. # [08:11] * Joins: maikmerten_ (n=merten@ls5laptop14.cs.uni-dortmund.de)
  164. # [08:11] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Read error: 110 (Connection timed out))
  165. # [08:13] * maikmerten_ is now known as maikmerten
  166. # [08:16] * Joins: roc (n=roc@121-72-0-77.dsl.telstraclear.net)
  167. # [08:17] * Quits: MikeSmith (n=MikeSmit@eM60-254-229-77.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  168. # [08:27] <othermaciej> if I were designing the UI for Safari my recommendation would probably be no pref setting at all
  169. # [08:37] <mpt> Hixie, I don't think there's any good way to phrase it without referring to the specific HTML attribute (and therefore delving into geekitude), because it controls only one of the ways by which a Web site can track your clicks
  170. # [08:37] <Hixie> mpt: possibly
  171. # [08:37] <mpt> To go back to your animated images example, in my dream browser that checkbox would control GIFs *and* Flash *and* JavaScript src-changes
  172. # [08:38] <Hixie> mpt: and <canvas> painting and DOM manipulation on a timer and meta refresh in an iframe?
  173. # [08:38] <mpt> probably :-)
  174. # [08:38] <Hixie> othermaciej: unfortunately that removes one of the main reasons to do it (though not all of the reasons that benefit the user, it must be said)
  175. # [08:39] <Hixie> mpt: that would be a very confusing pref
  176. # [08:39] <othermaciej> Hixie: I don't think "privacy extremists can turn it off" is a very good reason to do anything
  177. # [08:39] <othermaciej> at least, so far as Apple products go
  178. # [08:39] <Hixie> fair enough
  179. # [08:40] <othermaciej> I do think
  180. # [08:40] <othermaciej> "you can see the real link target"
  181. # [08:40] <othermaciej> is a good reason
  182. # [08:40] <othermaciej> (to the extent that seeing the link target is interesting at all, which it is somewhat)
  183. # [08:40] * mpt realizes he's not saying anything he didn't already say in October 2005
  184. # [08:41] <Hixie> i think the reduced latency is the second most important reason (the first being the "option for privacy extremists"), at least from google's perspective
  185. # [08:42] <othermaciej> from google's perspective, can't it have its own pref?
  186. # [08:42] <Hixie> (we already handle showing the right uri, by changing the uri at the last second when the user follows the link)
  187. # [08:42] <Hixie> well, the target audience likely isn't logged in
  188. # [08:42] <othermaciej> (though I guess privacy extremists wouldn't want to let google set a cookie)
  189. # [08:42] <Hixie> right
  190. # [08:43] <Hixie> there are a number of reasons to do this beyond just the privacy angle, of course
  191. # [08:43] <Hixie> latency, ui, reliability, etc
  192. # [08:43] <othermaciej> it might be reasonable to restrict it only to be able to ping the host that served the page
  193. # [08:44] <Hixie> that actually fails to address some of google's most important occurances of click tracking
  194. # [08:44] <Hixie> sadly
  195. # [08:44] <othermaciej> similar to the default cookie policy in Safari
  196. # [08:44] <Hixie> (e.g. adsense)
  197. # [08:45] <othermaciej> would adsense be ok with a form of click tracking that you could turn off?
  198. # [08:46] <Hixie> users come above profits
  199. # [08:46] <Hixie> so yes
  200. # [08:47] <Hixie> (obviously, that might change if a browser defaulted to disabling it)
  201. # [08:47] <Hixie> frankly we have bigger problems with false reported hits than false unreported hits
  202. # [08:47] <othermaciej> so you wouldn't want a browser to ship with the "ping every click counter [ 10 ] times" pref?
  203. # [08:48] <mpt> Even assuming this was a good idea, it looks to me like it would be a tragedy of the commons
  204. # [08:48] <othermaciej> tragedy of the commons?
  205. # [08:48] <mpt> The first browser to choose to default to ignoring ping= would be (slightly) faster than those that observed it
  206. # [08:49] <othermaciej> what's the scarce resource with no allocation policy in this case?
  207. # [08:49] <mpt> So other browsers would eventually ignore it to match, driving site authors back to using server-side redirects.
  208. # [08:49] <othermaciej> what you describe is (perhaps) a race to the bottom, not a tragedy of the commons
  209. # [08:49] <othermaciej> however, I don't think ping would be a significant perf hit
  210. # [08:49] <othermaciej> as long as you prioritize it lower than actual I/O for the page you are loading
  211. # [08:50] <mpt> The scarce resource being bandwidth
  212. # [08:50] <Hixie> actually the great thing about ping="" is it can be implemented in a way that totally avoids any performance hit
  213. # [08:50] <Hixie> which is, as noted above, the second most important reason google is interested in it
  214. # [08:51] <mpt> Send the ping once everything else has finished transferring?
  215. # [08:51] <Hixie> othermaciej: and yeah, such a pref would be a quick way to kill the feature from our point of view :-)
  216. # [08:51] <mpt> ... in all browser windows?
  217. # [08:51] <Hixie> mpt: right
  218. # [08:51] <mpt> ... and other Internet-using software you happen to have open?
  219. # [08:51] <Hixie> mpt: four TCP packets aren't even going to be a blip on the radar if you wait for a lull
  220. # [08:51] <mpt> true
  221. # [08:52] <othermaciej> it's not the bandwidth that kills you in the redirect case, it's the latency
  222. # [08:52] <Hixie> and that's all you need (SYN, SYN/ACK, ACK, HTTP POST, close connection)
  223. # [08:52] <Hixie> yeah
  224. # [08:52] * othermaciej loves saying "it's not the bandwidth, it's the latency"
  225. # [08:52] <Hixie> latency is all i care about these days
  226. # [08:52] <Hixie> bandwidth only matters when you're trying to watch video
  227. # [08:52] <othermaciej> it seems like the software engineer equivalent of "I'm a doctor, dammit, not an engineer"
  228. # [08:53] <Hixie> hah
  229. # [08:53] <othermaciej> bandwidth also matters when you are on EDGE and want to look at web sites
  230. # [08:53] <Hixie> i avoid such networks :-)
  231. # [08:54] <Hixie> i don't have any hardware even capable of connecting to such lame networks
  232. # [08:54] <Hixie> :-)
  233. # [08:54] <othermaciej> it certainly seems like such networks are on the way out
  234. # [08:54] <othermaciej> but latency is still a killer
  235. # [08:54] <othermaciej> this is why <script src=""> is worse than <img> for page loading performance
  236. # [08:55] <othermaciej> also why the http connection limit and the fact that pipelining is not practically usable taken together are bad
  237. # [08:55] <othermaciej> maybe sites should have some way to opt out of the connection limit
  238. # [08:58] <Hixie> <script async> baby
  239. # [08:59] <Hixie> the http limit is a pain, i agree
  240. # [08:59] <Hixie> not sure what to do about it
  241. # [08:59] <Hixie> there are sites that would quickly DOS themselves if it wasn't for that limit
  242. # [08:59] <Hixie> (e.g. flickr)
  243. # [09:02] <othermaciej> people ship Firefox extensions and Safari haxies to violate the connection limit for allegedly faster network perf
  244. # [09:02] <othermaciej> not sure if it works
  245. # [09:02] <othermaciej> another useful thing would be a reliable way for the site to report that it can support pipelining correctly
  246. # [09:02] <othermaciej> wait, that wouldn't work
  247. # [09:02] <othermaciej> I just remembered the reason we don't enable it is that apprently some proxies break in horrible ways
  248. # [09:03] <othermaciej> so an end-to-end header wouldn't help
  249. # [09:03] <othermaciej> can't remember if they are normal http proxies or transparent proxies
  250. # [09:03] <othermaciej> or indeed if they still exist
  251. # [09:03] <othermaciej> would flickr really blow up without the limit? (I have no idea)
  252. # [09:03] <Hixie> proxies are, from what i've heard in conversations with pretty much everyone who has ever deployed real end user software on the web, the worst pieces of software on the web
  253. # [09:04] <othermaciej> seems like with enough users, the connection limit won't actually reduce connections made per second
  254. # [09:04] <Hixie> i've heard horrible stories about proxies
  255. # [09:04] * Quits: roc (n=roc@121-72-0-77.dsl.telstraclear.net)
  256. # [09:04] <othermaciej> assuming constant time to serve a request
  257. # [09:04] <Hixie> if you have N users, and you remove the connection limit on a page with 20 images, you'll got from 2N connections to 21N+ connections
  258. # [09:04] <othermaciej> no, I think I am doing bad math there
  259. # [09:05] <Hixie> s/got/go/
  260. # [09:05] <othermaciej> I don't think max number of connections used would give the best perf, I doubt network stacks would schedule it that way
  261. # [09:06] <othermaciej> would probably just use more for data more likely to be latency-sensitive
  262. # [09:06] <Hixie> if you're selfish, and have ample bandwidth, why wouldn't opening as many connections as possible win?
  263. # [09:06] <othermaciej> and use some reasonable limit, like 4 or something, for images
  264. # [09:06] <othermaciej> pipelining would be better though
  265. # [09:06] <Hixie> what might help is to drop the connection limit for specific things, like <event-source> or TCPConnection (or whatever replaces them)
  266. # [09:07] <othermaciej> I guess it depends on how many it takes to saturate your bandwidth
  267. # [09:07] <othermaciej> once you've filled bandwidth adding more is bad
  268. # [09:07] <Hixie> sure
  269. # [09:07] <Hixie> and on dial-up that might be a concern
  270. # [09:07] <Hixie> and maybe even on low-end DSL or cable
  271. # [09:07] <Hixie> but there comes a point where you really aren't going to notice
  272. # [09:08] <Hixie> as far as i can tell
  273. # [09:08] <Hixie> anyway, i'm a doctor, not an engineer
  274. # [09:08] <Hixie> so...
  275. # [09:08] <Hixie> :-)
  276. # [09:08] <Hixie> i should sleep
  277. # [09:09] <Hixie> nn
  278. # [09:11] * Joins: MikeSmith (n=MikeSmit@eM60-254-219-185.pool.emnet.ne.jp)
  279. # [09:14] * Joins: roc (n=roc@121-72-19-73.dsl.telstraclear.net)
  280. # [09:18] <roc> there's got to be a way to detect bad proxies
  281. # [09:18] <roc> like maybe we set up a special test site
  282. # [09:19] <roc> and when pipelining is enabled in the browser, every time the user's IP address changes, we send a test HTTP pipelining transaction to the test site
  283. # [09:32] * Joins: tndH_ (i=Rob@87.102.22.166)
  284. # [09:32] * tndH_ is now known as tndH
  285. # [09:51] <othermaciej> roc: proxy config can change w/o IP change
  286. # [09:51] <othermaciej> generally that is detectable
  287. # [09:51] <othermaciej> dunno about the transparent proxy case
  288. # [09:52] <othermaciej> the problem really is that in the failure case it's not always obvious at a machine level that the response is currupted
  289. # [09:59] <roc> yeah
  290. # [09:59] <roc> someone can always bring up a transparent proxy that causes pipelining requests to be mangled/hang
  291. # [10:00] <roc> but we have to figure out a way to unbreak this part of the Web
  292. # [10:00] <roc> one day...
  293. # [10:15] <othermaciej> it is a problem worth solving, but pretty tough
  294. # [10:15] <othermaciej> ironically something like Google Web Accelerator could solve it
  295. # [10:15] <othermaciej> though perhaps it also obviates the need for it
  296. # [10:16] * Joins: ROBOd (n=robod@89.122.216.38)
  297. # [10:16] <Hixie> 1
  298. # [10:41] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  299. # [10:43] * Quits: MikeSmith (n=MikeSmit@eM60-254-219-185.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  300. # [11:03] * Joins: roc_ (n=roc@121-72-12-139.dsl.telstraclear.net)
  301. # [11:04] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  302. # [11:05] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Client Quit)
  303. # [11:14] * Quits: roc (n=roc@121-72-19-73.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  304. # [11:17] * Quits: kfish (n=conrad@61.194.21.25) (Remote closed the connection)
  305. # [11:17] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  306. # [11:18] * Joins: kfish (n=conrad@61.194.21.25)
  307. # [11:24] <hsivonen> where do I find the allowed whitespace positions in mime types?
  308. # [11:25] <hsivonen> surely text / plain is not allowed?
  309. # [11:26] <zcorpan> i remember this being discussed here (or in #html-wg) a few weeks ago
  310. # [11:27] <hsivonen> I figured that parsing media queries manually was a mistake, so I'm going with ANTLR for mime types
  311. # [11:28] <hsivonen> I haven't figured out yet how to get human-friendly error messages out of ANTLR, though
  312. # [11:29] <kfish> hsivonen, do you mean the allowed whitespace in something like "text/plain; charset=us-ascii (Plain text)" ?
  313. # [11:30] <hsivonen> kfish: yes. where is it defined that WS around the semicolon is OK but around the slash (presumably) not?
  314. # [11:30] <kfish> http://www.ietf.org/rfc/rfc2045.txt
  315. # [11:30] <hsivonen> hmm. I didn't find it there
  316. # [11:30] <kfish> section 5.1 has the bnf
  317. # [11:31] <kfish> content := "Content-Type" ":" type "/" subtype
  318. # [11:31] <kfish> where type and subtype are basically made of token
  319. # [11:31] <kfish> token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
  320. # [11:31] <kfish> or tspecials>
  321. # [11:32] <hsivonen> so where does it say that space after the semicolon is OK?
  322. # [11:32] <hsivonen> are where does it say that inter-token WS is always OK?
  323. # [11:32] <hsivonen> s/are/or/
  324. # [11:36] <Philip`> http://www.ietf.org/rfc/rfc2616.txt - "implied *LWS" "Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field."
  325. # [11:40] <hsivonen> Philip`: that would allow white space like this "text / html"
  326. # [11:40] <hsivonen> Philip`: is that actually supported?
  327. # [11:40] <kfish> and rfc822 explicitly allowed spaces around the @ in email addresses
  328. # [11:40] <hsivonen> kfish: scary
  329. # [11:41] <kfish> seems to have been cleaned up in 2822
  330. # [11:41] <kfish> (and newlines, i might add ...)
  331. # [11:41] <Philip`> data:text / html,<b>Test suggests maybe in Firefox
  332. # [11:47] <hsivonen> In addition, comments are allowed in accordance with RFC 822 rules for structured header fields.
  333. # [11:47] <hsivonen> argh. who came up with the idea of allowing comments in headers?
  334. # [11:49] <Philip`> http://philip.html5.org/demos/http/content-type/text-html vs http://philip.html5.org/demos/http/content-type/text-plain suggests IE/Firefox/Opera don't accept "text / html"
  335. # [11:50] <hsivonen> yay
  336. # [11:50] <hsivonen> time to send email I guess
  337. # [11:50] <Philip`> (Not sure why data:text / html,... works in Firefox)
  338. # [12:15] <hsivonen> were these RFCs written before there was a requirement for "rough consensus and *running code*" at the IETF?
  339. # [12:15] <hsivonen> I mean: one would think that actual implementors would have revolted over some of the gratuitous complexity
  340. # [12:16] * Joins: dolphinling (n=chatzill@rbpool5-22.shoreham.net)
  341. # [12:38] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  342. # [12:47] * Joins: annevk (n=annevk@c529c1b12.cable.wanadoo.nl)
  343. # [12:48] * Joins: Lachy (n=Lachy@pat-tdc.opera.com)
  344. # [12:59] <hsivonen> hmm. with RFC 2616 media type simplification rules, ANTLR looks like an overkill again...
  345. # [13:08] * hsivonen is unhappy due to time wasted over RFC 2045 considering that RFC 2616 is much better on the media type point
  346. # [13:09] <annevk> you could just ignore it
  347. # [13:09] <annevk> it's not even a comment on the intro doc
  348. # [13:18] <hsivonen> annevk: I didn't mean Julian's comments. I meant my efforts to implement conformance checking for attributes that take a MIME type optionally with parameters
  349. # [13:20] <hsivonen> I'm rather unhappy that I followed the normative reference to the MIME RFC rathole instead of realizing right away that I should have known to read RFC 2616 instead
  350. # [13:20] * Quits: roc_ (n=roc@121-72-12-139.dsl.telstraclear.net)
  351. # [13:31] * Quits: dolphinling (n=chatzill@rbpool5-22.shoreham.net) (zelazny.freenode.net irc.freenode.net)
  352. # [13:31] * Quits: mpt (n=mpt@222-152-129-82.jetstream.xtra.co.nz) (zelazny.freenode.net irc.freenode.net)
  353. # [13:31] * Quits: heycam (n=cam@124-168-2-82.dyn.iinet.net.au) (zelazny.freenode.net irc.freenode.net)
  354. # [13:31] * Quits: Lfe (n=lfe@bergstroem.nu) (zelazny.freenode.net irc.freenode.net)
  355. # [13:31] * Quits: bzed (n=bzed@devel.recluse.de) (zelazny.freenode.net irc.freenode.net)
  356. # [13:31] * Quits: tndH (i=Rob@87.102.22.166) (zelazny.freenode.net irc.freenode.net)
  357. # [13:31] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (zelazny.freenode.net irc.freenode.net)
  358. # [13:31] * Quits: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (zelazny.freenode.net irc.freenode.net)
  359. # [13:31] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) (zelazny.freenode.net irc.freenode.net)
  360. # [13:31] * Quits: takkaria (n=takkaria@isparp.co.uk) (zelazny.freenode.net irc.freenode.net)
  361. # [13:31] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (zelazny.freenode.net irc.freenode.net)
  362. # [13:31] * Quits: jgraham_ (n=jgraham@81-86-210-2.dsl.pipex.com) (zelazny.freenode.net irc.freenode.net)
  363. # [13:31] * Quits: YaaL (i=yaal@hell.pl) (zelazny.freenode.net irc.freenode.net)
  364. # [13:31] * Quits: wakaba_ (n=w@79.163.210.220.dy.bbexcite.jp) (zelazny.freenode.net irc.freenode.net)
  365. # [13:31] * Quits: toolskyn (i=toolskyn@amy.bdick.de) (zelazny.freenode.net irc.freenode.net)
  366. # [13:31] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (zelazny.freenode.net irc.freenode.net)
  367. # [13:31] * Quits: Hixie (i=ianh@trivini.no) (zelazny.freenode.net irc.freenode.net)
  368. # [13:31] * Quits: gavin (n=gavin@firefox/developer/gavin) (zelazny.freenode.net irc.freenode.net)
  369. # [13:31] * Quits: syp| (n=syp@lasigpc9.epfl.ch) (zelazny.freenode.net irc.freenode.net)
  370. # [13:31] * Joins: dolphinling (n=chatzill@rbpool5-22.shoreham.net)
  371. # [13:31] * Joins: mpt (n=mpt@222-152-129-82.jetstream.xtra.co.nz)
  372. # [13:31] * Joins: heycam (n=cam@124-168-2-82.dyn.iinet.net.au)
  373. # [13:31] * Joins: Lfe (n=lfe@bergstroem.nu)
  374. # [13:31] * Joins: bzed (n=bzed@devel.recluse.de)
  375. # [13:38] * Joins: gavin (n=gavin@firefox/developer/gavin)
  376. # [13:38] * Joins: syp| (n=syp@lasigpc9.epfl.ch)
  377. # [13:39] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  378. # [13:40] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
  379. # [13:41] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  380. # [13:41] * Joins: jgraham_ (n=jgraham@81-86-210-2.dsl.pipex.com)
  381. # [13:41] * Joins: YaaL (i=yaal@hell.pl)
  382. # [13:41] * Joins: wakaba_ (n=w@79.163.210.220.dy.bbexcite.jp)
  383. # [13:41] * Joins: Hixie (i=ianh@trivini.no)
  384. # [13:41] * Joins: toolskyn (i=toolskyn@amy.bdick.de)
  385. # [13:41] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  386. # [13:41] * Joins: tndH (i=Rob@87.102.22.166)
  387. # [13:41] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  388. # [13:41] * Joins: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  389. # [13:41] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  390. # [13:41] * Joins: takkaria (n=takkaria@isparp.co.uk)
  391. # [13:42] * Joins: roc (n=roc@121-72-12-21.dsl.telstraclear.net)
  392. # [13:42] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Nick collision from services.)
  393. # [13:42] * othermaciej_ is now known as othermaciej
  394. # [13:59] <annevk> hsivonen, ah, I see
  395. # [13:59] <annevk> somehow we need to solve the HTTP mess...
  396. # [13:59] <annevk> but I guess that's simply said...
  397. # [14:06] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  398. # [14:19] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  399. # [14:32] * Quits: annevk (n=annevk@c529c1b12.cable.wanadoo.nl)
  400. # [14:52] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  401. # [15:05] * Joins: ROBOd (n=robod@89.122.216.38)
  402. # [15:06] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  403. # [15:28] * Joins: csarven (n=nevrasc@81-5-133-33.static.nfwebsolutions.com)
  404. # [15:37] * Quits: jwalden (n=waldo@RANDOM-SIX-FIFTY.MIT.EDU) (Remote closed the connection)
  405. # [15:49] * Joins: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  406. # [16:16] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  407. # [16:38] * Joins: dglazkov_ (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  408. # [16:47] * Quits: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net) (Read error: 110 (Connection timed out))
  409. # [16:56] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  410. # [17:01] * Joins: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no)
  411. # [17:18] * Joins: grimeboy (n=grimboy@85.211.237.68)
  412. # [17:18] <gsnedders> Philip`, hsivonen: Implied LWS is explicitly disallowed around the slash in MIME types
  413. # [17:19] <Philip`> gsnedders: I think the problem was it isn't explicit in RFC2045
  414. # [17:19] <gsnedders> ah
  415. # [17:23] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  416. # [17:35] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  417. # [17:56] <Hixie> hsivonen: sorry about out of date references -- they're the best references i am aware of when i make the reference, but i have trouble keeping track of what's what, that's why i haven't updated them and why the section doesn't yet exist
  418. # [17:56] <Hixie> if i don't have a references section, people can't claim they're out of date
  419. # [17:56] <Hixie> at least that was the theory
  420. # [17:57] <Hixie> in practice people complain about as much, i just ignore them more :-)
  421. # [18:10] * Joins: webben (n=benh@81.168.106.209)
  422. # [18:12] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  423. # [18:30] * Quits: webben (n=benh@81.168.106.209) (Read error: 110 (Connection timed out))
  424. # [18:32] * Joins: KevinMarks (n=KevinMar@183.sub-75-210-77.myvzw.com)
  425. # [18:32] * Quits: KevinMarks (n=KevinMar@183.sub-75-210-77.myvzw.com) (Remote closed the connection)
  426. # [18:33] * Joins: heycam` (n=cam@210-84-13-228.dyn.iinet.net.au)
  427. # [18:39] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  428. # [18:43] * Quits: heycam (n=cam@124-168-2-82.dyn.iinet.net.au) (Read error: 113 (No route to host))
  429. # [18:44] <gsnedders> Lachy: yes
  430. # [18:48] * Joins: KevinMarks (i=KevinMar@nat/google/x-14849921acc0c392)
  431. # [18:50] <Lachy_> gsnedders, ?
  432. # [18:52] * Quits: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no) ("This computer has gone to sleep")
  433. # [18:54] * Joins: maikmerten (n=maikmert@L8c79.l.pppool.de)
  434. # [19:12] * Joins: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no)
  435. # [19:32] * Joins: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  436. # [19:35] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  437. # [19:45] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  438. # [19:46] * Quits: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Read error: 110 (Connection timed out))
  439. # [19:48] * Joins: phsiao_ (i=shawn@nat/ibm/x-c632c83a5a9456db)
  440. # [19:54] * Joins: Lachy__ (n=Lachlan@cm-84.215.41.149.getinternet.no)
  441. # [19:56] * Quits: Lachy__ (n=Lachlan@cm-84.215.41.149.getinternet.no) (Read error: 104 (Connection reset by peer))
  442. # [19:58] * Joins: grimboy_uk (n=grimboy@85-211-253-46.dsl.pipex.com)
  443. # [20:03] * Quits: Lachy_ (n=Lachlan@ti200710a340-2585.bb.online.no) (Read error: 110 (Connection timed out))
  444. # [20:03] * Joins: Lachy__ (n=Lachlan@cm-84.215.41.149.getinternet.no)
  445. # [20:04] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  446. # [20:06] <gsnedders> Lachy: accessing your site
  447. # [20:11] * Joins: grimboy (n=grimboy@85-211-246-191.dsl.pipex.com)
  448. # [20:11] * Quits: grimeboy (n=grimboy@85.211.237.68) (Read error: 110 (Connection timed out))
  449. # [20:14] * Quits: Lachy__ (n=Lachlan@cm-84.215.41.149.getinternet.no) (Read error: 104 (Connection reset by peer))
  450. # [20:14] * Joins: epeus (i=KevinMar@nat/google/x-e2dc252970d4f219)
  451. # [20:15] * Joins: Lachy_ (n=Lachlan@cm-84.215.41.149.getinternet.no)
  452. # [20:15] * Quits: KevinMarks (i=KevinMar@nat/google/x-14849921acc0c392) (Nick collision from services.)
  453. # [20:15] * epeus is now known as KevinMarks
  454. # [20:16] * Quits: roc (n=roc@121-72-12-21.dsl.telstraclear.net)
  455. # [20:23] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  456. # [20:25] * Quits: grimboy_uk (n=grimboy@85-211-253-46.dsl.pipex.com) (Read error: 110 (Connection timed out))
  457. # [20:27] * Quits: phsiao_ (i=shawn@nat/ibm/x-c632c83a5a9456db)
  458. # [20:27] * Joins: phsiao (i=shawn@nat/ibm/x-039468c74d424021)
  459. # [20:57] * Quits: maikmerten (n=maikmert@L8c79.l.pppool.de) ("Leaving")
  460. # [20:58] * Quits: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Remote closed the connection)
  461. # [20:59] * Joins: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  462. # [21:17] * Joins: roc (n=roc@202.180.114.137)
  463. # [21:20] * Joins: psa (n=yomode@posom.com)
  464. # [21:21] * Quits: phsiao (i=shawn@nat/ibm/x-039468c74d424021)
  465. # [21:21] * hsivonen wonders if HTTP implementations really support backslash escaping control chararacters...
  466. # [21:21] * Quits: Lachy_ (n=Lachlan@cm-84.215.41.149.getinternet.no) ("This computer has gone to sleep")
  467. # [21:34] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  468. # [21:35] * Joins: Lachy_ (n=Lachlan@cm-84.215.41.149.getinternet.no)
  469. # [21:36] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  470. # [21:43] * Joins: phsiao (i=shawn@nat/ibm/x-1a5de01dc10ff16f)
  471. # [21:59] * Joins: doublec (n=doublec@202.180.114.137)
  472. # [22:01] * Quits: phsiao (i=shawn@nat/ibm/x-1a5de01dc10ff16f) (Read error: 104 (Connection reset by peer))
  473. # [22:02] * Joins: phsiao (i=shawn@nat/ibm/x-84fb4c38b70736d8)
  474. # [22:03] * Quits: KevinMarks (i=KevinMar@nat/google/x-e2dc252970d4f219) ("The computer fell asleep")
  475. # [22:06] * Quits: phsiao (i=shawn@nat/ibm/x-84fb4c38b70736d8) (Client Quit)
  476. # [22:06] * Joins: phsiao (i=shawn@nat/ibm/x-d18608fc77aa2ea0)
  477. # [22:17] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  478. # [22:21] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  479. # [22:25] * Joins: KevinMarks (i=KevinMar@nat/google/x-12822922022df965)
  480. # [22:26] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  481. # [22:27] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  482. # [22:31] <gsnedders> hsivonen: Mozilla in places just keeps the slashes and everything until double quote not preceeded by a slash
  483. # [22:33] <hsivonen> gsnedders: is there a bug filed? what do other browsers do?
  484. # [22:33] <gsnedders> hsivonen: dunno.
  485. # [22:33] <gsnedders> hsivonen: I've had so little time to reverse engineer such things
  486. # [22:34] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  487. # [22:34] <gsnedders> hsivonen: Mozilla doesn't have a unified place for decoding quoted-string, and does it all over the place
  488. # [22:50] * Quits: dglazkov_ (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  489. # [23:16] * Joins: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  490. # [23:23] * Quits: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Remote closed the connection)
  491. # [23:24] * Joins: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com)
  492. # [23:24] * Quits: weinig_ (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Remote closed the connection)
  493. # [23:29] * Quits: weinig (n=weinig@cpe-66-108-205-3.nyc.res.rr.com) (Read error: 110 (Connection timed out))
  494. # [23:34] * Joins: tantek (n=tantek@70.13.64.126)
  495. # [23:36] * Quits: jgraham (n=james@81-86-210-2.dsl.pipex.com) ("This computer has gone to sleep")
  496. # [23:43] * Joins: jgraham (n=james@81-86-210-2.dsl.pipex.com)
  497. # Session Close: Tue Nov 20 00:00:00 2007

The end :)