/irc-logs / w3c / #html-wg / 2009-03-30 / end

Options:

  1. # Session Start: Mon Mar 30 00:00:00 2009
  2. # Session Ident: #html-wg
  3. # [00:02] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  4. # [00:39] * Joins: heycam (cam@130.194.73.110)
  5. # [00:39] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  6. # [00:51] * Joins: karl (karlcow@128.30.54.58)
  7. # [00:53] * Quits: Shunsuke (Shunsuke@219.94.192.74) (Client exited)
  8. # [00:53] * Joins: Lachy (Lachlan@85.196.122.246)
  9. # [00:54] * Quits: tH (Rob@129.11.83.14) (Quit: ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406])
  10. # [00:59] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  11. # [02:26] * Quits: maddiin (mc@87.185.193.157) (Quit: maddiin)
  12. # [03:20] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  13. # [03:31] * Joins: Zeros (Zeros-Elip@68.50.195.181)
  14. # [04:37] * Quits: Zeros (Zeros-Elip@68.50.195.181) (Ping timeout)
  15. # [04:37] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  16. # [04:58] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Ping timeout)
  17. # [05:21] * Joins: Zeros (Zeros-Elip@68.50.195.181)
  18. # [08:05] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
  19. # [08:53] * Joins: tH (Rob@129.11.83.14)
  20. # [09:49] * Joins: heycam (cam@124.168.80.126)
  21. # [10:21] * Quits: Zeros (Zeros-Elip@68.50.195.181) (Ping timeout)
  22. # [10:27] * Joins: Zeros (Zeros-Elip@68.50.195.181)
  23. # [10:48] * Joins: ROBOd (robod@89.122.216.38)
  24. # [11:43] * Quits: Zeros (Zeros-Elip@68.50.195.181) (Quit: This computer has gone to sleep)
  25. # [11:48] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  26. # [12:08] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  27. # [12:21] * Joins: sryo1 (sryo@190.245.204.198)
  28. # [12:21] * Quits: sryo (sryo@190.245.204.198) (Ping timeout)
  29. # [12:25] * Joins: Lachy (Lachlan@213.236.208.22)
  30. # [12:31] * Joins: Julian (chatzilla@217.91.35.233)
  31. # [13:01] * Joins: myakura (myakura@122.29.116.63)
  32. # [14:00] * Quits: heycam (cam@124.168.80.126) (Quit: bye)
  33. # [14:08] * Quits: anne (annevk@77.163.243.203) (Ping timeout)
  34. # [14:10] * Joins: anne (annevk@77.163.243.203)
  35. # [14:10] <anne> Julian, how do I raise issues with the HTTP WG? E.g. that Location needs to handle spaces and other invalid URI characters?
  36. # [14:15] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  37. # [14:17] <Julian> You send an email to the HTTP WG's mailing list. If there's agreement that something needs to be done, the chair or one of the editors will open a ticket.
  38. # [14:19] <anne> Which of the various drafts discusses Location?
  39. # [14:21] <anne> found it
  40. # [14:22] <anne> seems there are multiple issues
  41. # [14:29] <anne> I guess I'll try
  42. # [14:29] <anne> so far my experience with the HTTP WG is that they're not that interested in dealing with stuff like this
  43. # [14:36] <Julian> Like "error handling". Indeed. I happen to agree to that point of view.
  44. # [14:37] <anne> yeah, because of that HTTP specs (and other IETF material) is mostly useless for us :(
  45. # [14:38] <hsivonen> anne: "us" being Opera?
  46. # [14:40] <MikeSmith> I have to say that I wasn't terrifically encouraged by the discussion and response from the HTTP WG about the Origin header
  47. # [14:41] <Julian> "useless" != "does not contain everything we want them to contain", methinks
  48. # [14:41] <anne> hsivonen, yeah, though I assume the same goes for other browser vendors
  49. # [14:41] <anne> hsivonen, e.g. the cookie specs are pure fiction I'm told
  50. # [14:42] <MikeSmith> Julian: what was your take on the discussion about the Origin header?
  51. # [14:43] <MikeSmith> was the conclusion of the discussion pretty much an inevitability? or is there something more that Adam or others could have done to make that case better?
  52. # [14:43] <hsivonen> anne: the Apache Commons HTTP Client can be configured to comply or to work when it comes to cookies, IIRC...
  53. # [14:43] <Julian> Mike: I try to stay away from security discussions.
  54. # [14:43] <anne> Julian, ok, the global idea is there, but all the details need to be reverse engineered
  55. # [14:44] <MikeSmith> Julian: heh. me too, as much as possible
  56. # [14:44] <anne> Julian, that qualifies is mostly useless to me
  57. # [14:44] <MikeSmith> politics, religion, and security
  58. # [14:44] <Julian> Mike: if the required functionality can be retrofitted into Referer, that would be great.
  59. # [14:45] <MikeSmith> right. but if it can't ...
  60. # [14:45] <Julian> Mike: that being said, I personally wasn't convinced either way.
  61. # [14:46] <MikeSmith> I didn't see much substantive comments on the data Adam presented from the experiment he did (the one documented in his paper)
  62. # [14:46] <Julian> Mike: as far as I can tell, we're making progress on the HTML5/IETF relations, so maybe we'll make progress there as well
  63. # [14:47] <MikeSmith> yeah, we need to
  64. # [14:48] <anne> and the idea that browsers are just one of many clients is fine, except that we do have an affect on behavior of other clients long term so it would be nice if our feedback was not simply dismissed as implementation bugs
  65. # [14:49] <hsivonen> what happened with Origin at the IETF f2f?
  66. # [14:50] <anne> first reply I get on this Location thingie is how stupid browsers are
  67. # [14:50] <MikeSmith> I personally don't find that idea that browsers are just one of many clients to be a very realistic way of looking at things.
  68. # [14:51] <anne> well duh
  69. # [14:52] <anne> but that's mostly because browsers just got widely popular so all bugs have a wide impact (and don't tell me all these other HTTP guys write perfect software)
  70. # [14:52] <Julian> Mike: depends on where you come from. I've spent lots of time using HTTP for non-browser use cases, so I happen to agree with that point of view.
  71. # [14:53] <jgraham> Julian: Do you agree that it is de-facto the case that to work in the web context, http clients have to behave like browsers?
  72. # [14:54] <anne> Julian, are those also non-public use cases? E.g. do you operate in a "walled garden"?
  73. # [14:55] <anne> Julian, where you control both the client and server software
  74. # [14:56] <Julian> James: no.
  75. # [14:57] <Julian> Anne: no. For instance, consider WebDAV and AtomPub.
  76. # [14:58] <anne> while interesting, you don't really need to interoperate with browsers for such content so I can see why you don't care
  77. # [15:01] <jgraham> WebDAV and AtomPub somehow don't feel like the web
  78. # [15:01] <Julian> well, there can be overlap (in that the same resource is served to browsers as well); but in my experience, servers implementing HTTP for things like WebDAV as well happen to be better on the conformance front as well.
  79. # [15:01] <Julian> James: to you.
  80. # [15:01] <anne> though presumably when XMLHttpRequest support becomes better and WebDAV and AtomPub are used from that (dunno) Location related "bugs" (and others) might effect you at some point if the server is not entirely compliant
  81. # [15:01] <jgraham> (Also, I still can't find an AtomPub client that I can make work)
  82. # [15:02] <anne> Julian, yeah, but writing the HTTP spec without considering the needs of all the servers and clients is not too nice
  83. # [15:04] * Joins: maddiin (mc@87.185.197.4)
  84. # [15:04] * Philip wonders if you could write an SVN client using XHR
  85. # [15:06] <Julian> Anne, we're not writing it, we are revising it. And we can't make changes that break existing implementations.
  86. # [15:07] * Philip noticed that SVN 1.6 finally added support for http://svnrepo/file?r=123 so you can access non-latest revisions without having a WebDAV client
  87. # [15:07] * MikeSmith wonders if he can find an svn client that actually responds to ^C
  88. # [15:07] <Philip> Julian: Does "existing implementations" mean "existing perfectly-conforming implementations"?
  89. # [15:08] <Julian> Philip: you could, when the XHR implementation supports then necessary methods (so IE's native XHR is out, and so is Opera), and if you don't need to support binary content.
  90. # [15:09] <Julian> Philip: it may or may not. What I'm trying to say is that we're really restricted by our charter in what we can change.
  91. # [15:09] <anne> another problem with the HTTP WG is that it's full of people frustrated with browsers for one reason or another
  92. # [15:09] <anne> much like the XHTML2 WG
  93. # [15:09] <Philip> MikeSmith: The standard svn client (1.5.5) seems to handle ctrl-C perfectly well when I try it
  94. # [15:09] <Philip> anne: Much like the world :-)
  95. # [15:09] <anne> so it's really hard to get any productive discussion
  96. # [15:10] <Julian> Anne: that could be fixed ny more browser people participating.
  97. # [15:10] <Julian> s/ny/by/
  98. # [15:10] <anne> Julian, I have attempted that at various points but I just get laughed at, called stupid, etc.
  99. # [15:10] <anne> Julian, not a whole lot of fun
  100. # [15:11] <anne> I just tried it again though
  101. # [15:11] <anne> same result so far
  102. # [15:11] <anne> I believe for Content-Location Eric from Microsoft also participated
  103. # [15:11] <anne> and Maciej from Apple
  104. # [15:11] <anne> no luck
  105. # [15:11] <MikeSmith> Philip: svn command-line client in my Debian environment responds to ^C for me only after a long delay. no clue what it's doing in the mean time. svn client provides very little troubleshooting info when it fails or hangs
  106. # [15:13] <anne> David Baron from Mozilla also gave feedback on Content-Location
  107. # [15:13] <anne> that's pretty much all browser vendors that matter
  108. # [15:13] <Philip> MikeSmith: 1.5? http://subversion.tigris.org/svn_1.5_releasenotes.html#cancellation-improvements says some improvements were made there
  109. # [15:13] <pimpbot> Title: subversion: Subversion 1.5 Release Notes (at subversion.tigris.org)
  110. # [15:14] <Julian> Content-Location should be on the issues list (but currently IMHO isn't); but the fix isn't to remove it (as it's widely used)
  111. # [15:15] <anne> IMHO?
  112. # [15:16] <MikeSmith> Philip: thanks. I'm running 1.5.6 but not noticing much changes. e.g., when I run a checkout of validator.nu sources, still hangs for me when I try to cancel with ^C
  113. # [15:17] <Philip> MikeSmith: Oh, okay then
  114. # [15:17] <Philip> MikeSmith: (Is that going indirectly through a Python build script, rather than being plain svn?)
  115. # [15:18] <MikeSmith> Philip: through the build script. so admittedly it could be the script
  116. # [15:18] <Julian> http://en.wikipedia.org/wiki/IMHO
  117. # [15:18] <pimpbot> Title: List of acronyms and initialisms: I - Wikipedia, the free encyclopedia (at en.wikipedia.org)
  118. # [15:19] <MikeSmith> but having had the same problem with svn and other repositories, I'm more inclined to blame svn
  119. # [15:19] <anne> Julian, oh ok, but it's not an opinion right?
  120. # [15:20] <Julian> Anne, I'd have to check.
  121. # [15:21] <anne> Julian, right, I think you're using it incorrectly :)
  122. # [15:21] <Philip> Would "IIRC" be more appropriate?
  123. # [15:21] <anne> Julian, btw, I also gave charter feedback: http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg222
  124. # [15:21] <pimpbot> Title: ietf-http-wg@w3.org from January to March 2007: by thread (at lists.w3.org)
  125. # [15:22] <anne> Julian, and I don't think http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0273.html is acted upon
  126. # [15:22] <pimpbot> Title: RE: Redirection of a POST as a GET from Eric Lawrence on 2007-03-09 (ietf-http-wg@w3.org from January to March 2007) (at lists.w3.org)
  127. # [15:22] <anne> Julian, that's feedback from virtually every browser client on the planet
  128. # [15:23] <anne> (that redirection rules cannot be implemented as is)
  129. # [15:25] <anne> and I'm sure there are charter excuses (partially due to dismissed feedback) and other clients and whatnot, but in the end it just seems like the HTTP WG isn't willing to play ball
  130. # [15:32] <Julian> Anne, I can only recommend to participate. If you think the WG does not follow the IETF process, complain (on the list, to the chair, to the Area Director...)
  131. # [15:33] * Joins: rubys (rubys@75.182.92.38)
  132. # [15:34] <anne> I'm not familiar with the process. But frankly, it doesn't really matter. The WG is not interested in addressing it and trying to make them do it anyway by complaining is unlikely to be productive.
  133. # [15:37] <anne> I'll probably keep raising issues anyway if I run across them for documentation purposes, but not with the expectation that 2616bis will actually be more useful for me.
  134. # [15:38] <hsivonen> anne: is anyone (gsnedders perhaps?) maintaining a list of issues that implementors need to know but the 2616bis won't mention?
  135. # [15:38] <anne> It's pretty sad state of affairs though that the primary use case of HTTP is in such a bad state and left unaddressed by the WG because they do not care about non-conforming clients.
  136. # [15:42] <anne> hsivonen, I don't think so; that does give inspiration for a WHATWG wiki page :)
  137. # [15:44] <hsivonen> anne: caring more about HTTP use cases other than a Web browser talking to a Web server indeed is similar to caring more about XHTML2 reuse in ebooks or the backplane than as a delivery format to browsers
  138. # [15:48] * Joins: DanC (connolly@128.30.52.30)
  139. # [15:49] <DanC> ACTION: Dan to reformat the document on URLs in HTML 5 as an Internet Draft
  140. # [15:49] * trackbot noticed an ACTION. Trying to create it.
  141. # [15:49] <trackbot> Created ACTION-118 - Reformat the document on URLs in HTML 5 as an Internet Draft [on Dan Connolly - due 2009-04-06].
  142. # [15:53] <anne> DanC, FYI, at least CSS requires the same handling
  143. # [15:53] <anne> DanC, I'm would expect e.g. SVG to require the same handling too, but I haven't verified
  144. # [15:54] <DanC> you mentioned that in email before... and I think you elaborated in a blog item... is there news since then?
  145. # [15:54] * DanC wishes for a test case for SVG and URLs
  146. # [15:55] <anne> I verified it for CSS
  147. # [15:55] * DanC thought that was the subject of the blog posting... checks...
  148. # [15:56] <DanC> http://annevankesteren.nl/2009/03/urls
  149. # [15:56] <pimpbot> Title: URLs are tough — Anne’s Weblog (at annevankesteren.nl)
  150. # [15:56] <anne> I made tests for CSS too, but they're not nice pass/fail
  151. # [15:56] <anne> you have to check a log to see what actually happened
  152. # [15:57] <anne> i.e. load 001.htm or 002.htm in http://dump.testsuite.org/2009/urlcrap/ and then check log.txt
  153. # [15:57] <pimpbot> Title: Index of /2009/urlcrap (at dump.testsuite.org)
  154. # [15:57] <DanC> so your css testing is since "URLs are tough?"
  155. # [15:57] <anne> yes
  156. # [15:57] <anne> DanC, http://lists.w3.org/Archives/Public/www-style/2009Mar/0321.html is my testing report
  157. # [15:57] <pimpbot> Title: [css21] CSS URL handling from Anne van Kesteren on 2009-03-24 (www-style@w3.org from March 2009) (at lists.w3.org)
  158. # [15:58] * DanC wonders who's behind testsuite.org ... looks it up... loses: "Registrant Name:testsuite.org Private Registrant"
  159. # [15:58] <DanC> issue-56: <anne> DanC, http://lists.w3.org/Archives/Public/www-style/2009Mar/0321.html is my testing report
  160. # [15:58] * trackbot attempting to add a note to ISSUE-56.
  161. # [15:58] <trackbot> ISSUE-56 Assess whether "URLs" section/definition conflicts with Web architecture notes added
  162. # [15:58] <pimpbot> Title: [css21] CSS URL handling from Anne van Kesteren on 2009-03-24 (www-style@w3.org from March 2009) (at lists.w3.org)
  163. # [15:59] <anne> private? hmm, it's me
  164. # [15:59] <anne> oh, maybe I set it to private because that's easier than keeping my info up to date
  165. # [15:59] <DanC> "private" as in: don't feed my email address to the spammers via whois, I suspect.
  166. # [16:00] <anne> oh no, that already failed :)
  167. # [16:01] <DanC> how about using a DVCS for testsuite.org? my favorite is hg, but I could deal with git or bzr
  168. # [16:01] <ed_work> DanC: IIRC Martin Duerst produced a rather extensive testsuite for IRI:s in svg
  169. # [16:02] <anne> DanC, I like that I can just dump raw files there over sshfs
  170. # [16:03] <DanC> well, I'll keep wishing, anne. an audit trail will eventually be cost-effective, if "testsuite.org" lives up to its name
  171. # [16:04] <DanC> ed_work, a quick search yields Martin asking for help with testing. http://markmail.org/message/yd3voh537frixabu
  172. # [16:04] <pimpbot> Title: RE: I-D Action:draft-duerst-iri-bis-02.txt - Martin Duerst - org.w3.public-iri - MarkMail (at markmail.org)
  173. # [16:04] <DanC> I don't see the tests themselves.
  174. # [16:04] <anne> agreed, I'm afraid testsuite.org won't quite live up to its name or promise though
  175. # [16:04] * DanC sighs at the fact that google prefers markmail's archive to w3.org's
  176. # [16:05] <DanC> umm... then why did you take the name, anne?
  177. # [16:05] <DanC> amen to this: "If there is one thing the world needs, it’s more testcases." -- http://testsuite.org/
  178. # [16:06] <anne> http://www.sw.it.aoyama.ac.jp/2005/iritest/SVG/index.html
  179. # [16:06] <pimpbot> Title: SVG Tests (at www.sw.it.aoyama.ac.jp)
  180. # [16:06] <ed_work> anne: yep, I think that's the one
  181. # [16:07] <DanC> issue-56: http://www.sw.it.aoyama.ac.jp/2005/iritest/SVG/index.html SVG/IRI Tests by Martin
  182. # [16:07] * trackbot attempting to add a note to ISSUE-56.
  183. # [16:07] <trackbot> ISSUE-56 Assess whether "URLs" section/definition conflicts with Web architecture notes added
  184. # [16:07] <pimpbot> Title: SVG Tests (at www.sw.it.aoyama.ac.jp)
  185. # [16:07] <ed_work> ...less extensive than I remembered, but still :)
  186. # [16:07] <anne> we fail tests
  187. # [16:08] <DanC> speaking of DVCS, I suppose I should update http://bitbucket.org/DanC/markup-spec/ ..
  188. # [16:08] <pimpbot> Title: DanC / markup-spec / overview bitbucket.org (at bitbucket.org)
  189. # [16:08] <anne> guess that means either the tests are borked or they assume things of IRIs we do not implement
  190. # [16:08] <anne> because we implement "URLs" instead (which would make sense)
  191. # [16:09] <hsivonen> I don't understand why other things can reuse names for revisions, but with *R*s, every revision needs a new name
  192. # [16:09] <hsivonen> like URL, URI, IRI, LEIRI
  193. # [16:10] <anne> well, IRIs are a syntactic sugar
  194. # [16:10] <Julian> Henri, these are not revisions but different things.
  195. # [16:10] <anne> LEIRIs are even more syntactic sugar
  196. # [16:10] <DanC> LMM proposes that we're revising IRIs
  197. # [16:10] <anne> URIs is the real deal
  198. # [16:10] <jgraham> Because people have the notion that *R*'s are really fundamental and so can't be changed
  199. # [16:10] <anne> and URL is what's actually implemented :p
  200. # [16:11] <DanC> there's an observable distinction between URIs-on-the-wire-in-http and IRIs-in-href-attrs.
  201. # [16:11] <anne> DanC, not in IE6 for the query component by the way, as it happens
  202. # [16:11] <hsivonen> I thought we had URL with an ASCII serialization and an Unicode serialization
  203. # [16:12] <hsivonen> and a mapping from the Unicode serialization to the ASCII serialization
  204. # [16:12] <anne> DanC, maybe also for newer IEs, haven't tested
  205. # [16:12] <DanC> hsivonen, I guess 2 serializations for URLs is coherent
  206. # [16:13] <anne> ed_work, have you played with those tests? they seem bogus
  207. # [16:13] <ed_work> anne: not much no, just ran a few of them now...
  208. # [16:14] <anne> ed_work, it seems they are not well-formed even or are those really U+FFFD characters in the source?
  209. # [16:14] <DanC> ed_work, have we met? I'm Dan Connolly (photo etc: http://www.w3.org/People/Connolly/ )
  210. # [16:14] <pimpbot> Title: Dan Connolly, W3C (at www.w3.org)
  211. # [16:15] <anne> ed_work, http://validator.nu/?doc=http%3A%2F%2Fwww.sw.it.aoyama.ac.jp%2F2005%2Firitest%2FSVG%2FLegacyHuman%2Fiso-8859-1_fr%2Fa_xlink_href%2Findex.svg
  212. # [16:15] <pimpbot> Title: Validation results for http://www.sw.it.aoyama.ac.jp/2005/iritest/SVG/LegacyHuman/iso-8859-1_fr/a_xlink_href/index.svg (at validator.nu)
  213. # [16:16] <anne> ed_work, if I fix the encoding through the encoding menu (that should actually not be enabled for XML, but whatever) then they do work...
  214. # [16:16] * DanC wishes for somebody to capture these test results in machine-readable form... a la http://dig.csail.mit.edu/breadcrumbs/node/171
  215. # [16:16] <pimpbot> Title: Decentralized Information Group (DIG) Breadcrumbs (at dig.csail.mit.edu)
  216. # [16:16] <ed_work> DanC: I think so, though I'm not 100% sure...probably at the last TPAC, I'm Erik Dahlström if that wasn't clear
  217. # [16:16] <anne> DanC, well, the tests are bogus
  218. # [16:17] <DanC> ah... indeed, that wasn't clear. Hi, ed
  219. # [16:17] <DanC> all of the tests are bogus?
  220. # [16:17] <ed_work> no, some of the tests are ok I think
  221. # [16:19] * anne would hope that the bit of SVG that maps to CSS uses the CSS codepath
  222. # [16:20] <anne> so there's a dependency there
  223. # [16:20] <anne> i guess I can make a few simple tests that answers the simple questions
  224. # [16:25] * Quits: Julian (chatzilla@217.91.35.233) (Quit: ChatZilla 0.9.84 [Firefox 3.0.8/2009032609])
  225. # [16:26] <DanC> anne, pick one or two of the broken tests for me, please?
  226. # [16:26] * Joins: Julian (chatzilla@217.91.35.233)
  227. # [16:29] <ed_work> http://www.sw.it.aoyama.ac.jp/2005/iritest/SVG/LegacyHuman/iso-8859-1_fr/rect_fill/index.svg should specify its encoding
  228. # [16:29] <pimpbot> Title: IRITests - LegacyHuman - SVG - Element - Attributefill (at www.sw.it.aoyama.ac.jp)
  229. # [16:29] <ed_work> that's one example that looks broken
  230. # [16:32] <anne> DanC, the first two tables after the ASCII table are completely broken
  231. # [16:33] <DanC> ok. thanks.
  232. # [16:33] <anne> Firefox and Safari do document encoding for the URL character encoding and Opera UTF-8 for <a xlink:href> in SVG
  233. # [16:35] * Joins: aroben (aroben@71.58.77.15)
  234. # [16:37] <anne> Safari also converts \ to /; the other two escape it
  235. # [16:37] <anne> spaces and such are handled as per the URL draft obviously
  236. # [16:41] <anne> Firefox uses UTF-8 for the query component when the characters do not fit
  237. # [16:43] <anne> nobody does normalization again, except for WebKit, which even normalizes for Unicode encoded documents
  238. # [16:44] <anne> (in other words, browsers share code path for SVG too as was to be expected)
  239. # [16:51] <anne> (In case anyone was wondering, HTML and XHTML do the same.)
  240. # [16:56] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  241. # [16:56] * Joins: Lachy (Lachlan@213.236.208.22)
  242. # [17:01] <anne> DanC, the last two tables are also bogus, the rest works fine
  243. # [17:14] <anne> I guess you can test this automatically be letting a UA do a number of requests by running it through tests with JS and then in the end check all the reqeusts it made and compare it to some desired outcome list.
  244. # [17:16] <anne> Shouldn't be too hard I suppose if you ensure that the requests have some form of uniqueness.
  245. # [17:17] <jgraham> anne: Why not set up hg.testsuites.org wwith bitbucket as the backend or something?
  246. # [17:21] <anne> because I don't need it?
  247. # [17:22] <jgraham> anne: Ah, well if you're not interested in other people's testcases it doesn't matter much
  248. # [17:22] <jgraham> (except to the other people who are interested in your testcases)
  249. # [17:26] <anne> if I was actually hosting proper tests there I'd be more sympathetic to the request
  250. # [17:26] * Joins: tlr (tlr@128.30.52.30)
  251. # [17:30] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  252. # [17:35] * Joins: MichaelC (Michael@128.30.52.30)
  253. # [18:25] <gsnedders> hsivonen: I intend to have such a list as an appendix to http-parsing
  254. # [18:42] * Joins: Lachy (Lachlan@85.196.122.246)
  255. # [18:46] <anne> here's a start: http://wiki.whatwg.org/wiki/HTTP_Issues
  256. # [18:46] <pimpbot> Title: HTTP Issues - WHATWG Wiki (at wiki.whatwg.org)
  257. # [18:47] * Joins: dougt (dougt@71.198.208.205)
  258. # [18:48] <anne> there's a lot more of course, e.g. pipelining is a mess
  259. # [19:02] <Julian> how so? spec-wise or implementation-wise?
  260. # [19:11] <anne> web-wise
  261. # [19:12] <anne> I'm not sure why you ask, since you know the answer
  262. # [19:14] <Julian> I'm asking what kind of change you're looking for.
  263. # [19:14] * Joins: adele (adele@17.246.18.119)
  264. # [19:16] <anne> spec-change I suppose, since we cannot directly support what is there now
  265. # [19:16] <Julian> what change in the spec would allow you to use it?
  266. # [19:17] <anne> obsoleting it would work :)
  267. # [19:17] <anne> dunno exactly, I haven't researched it
  268. # [19:17] <Julian> How would that help?
  269. # [19:18] <Julian> There are users of pipelining (subversion comes to mind), so I don't see why the feature should be removed.
  270. # [19:19] <Julian> Documenting the various implementation issues would be good. For instance, in an impl report, published as Informational RFC.
  271. # [19:21] <anne> I don't really see how that would help implementations converge; how that would help authors trying to use the feature and finding that it fails, etc.
  272. # [19:22] <anne> It might help new implementors avoiding the feature I suppose
  273. # [19:28] <Julian> I just decided to turn on pipelining in Firefox, just to find out I had done it long ago already.
  274. # [19:37] * Joins: smedero (smedero@66.114.145.154)
  275. # [19:40] * Joins: Sander (svl@86.87.68.167)
  276. # [19:45] * Quits: myakura (myakura@122.29.116.63) (Quit: Leaving...)
  277. # [20:20] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  278. # [20:21] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  279. # [21:28] * Joins: heycam (cam@130.194.73.110)
  280. # [21:28] * Parts: rubys (rubys@75.182.92.38)
  281. # [21:29] * Philip sees pipeline-related discussion in Mozilla #developers
  282. # [21:29] <Philip> "we tried to turn it on for Fx3" / "It broke hsbc online banking" / "iirc the problem was that it broke a handful of things in strange semi-random ways that weren't obviously related to pipelining"
  283. # [21:31] <Philip> and https://bugzilla.mozilla.org/show_bug.cgi?id=422978
  284. # [21:31] <pimpbot> Title: Bug 422978 pipelining breaks secure Internet banking websites (at bugzilla.mozilla.org)
  285. # [22:07] * Joins: Lachy (Lachlan@85.196.122.246)
  286. # [22:17] * Joins: rubys (rubys@75.182.92.38)
  287. # [22:39] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  288. # [22:56] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  289. # [23:20] * Parts: rubys (rubys@75.182.92.38)
  290. # [23:23] * Joins: dbaron (dbaron@63.245.220.241)
  291. # [23:32] * Quits: sryo1 (sryo@190.245.204.198) (Connection reset by peer)
  292. # [23:32] * Joins: sryo (sryo@190.245.204.198)
  293. # Session Close: Tue Mar 31 00:00:00 2009

The end :)