- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Sun, 3 Oct 2010 12:48:41 -0600
- To: Adam Barth <w3c@adambarth.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Adam Barth wrote: > > Jungshik Shin says "There are a lot of web sites that do what's > expected by IE." > http://code.google.com/p/chromium/issues/detail?id=118#c1 > I do not see the relevance of user agent implementation concerns, to HTTP defining what constitutes conformant messaging syntax. Provided I'm sending conformant syntax, any user agent will understand what I intend. How can HTTP specify the filename must be decoded, when that's dependent on the filesystem allowing the decoded characters? It is not required that HTTP be over-specified to account for every edge-case of nonconformant syntax. > > Do you have evidence that, for example, the percent encoding is rarely > used? In the absence of evidence, it's unlikely implementations will > remove support for the behavior. > Provided a user agent understands my conformant syntax, that user agent is conformant with HTTP. If that user agent also interprets non- conformant syntax, that doesn't mean the user agent doesn't conform to HTTP. I don't see any requirement being imposed on browsers by this draft, to remove support for whatever behavior they require or desire. It is not required for the draft author to present evidence that the percent encoding is rarely used. That entire line of logic simply does not apply to HTTP. Think about my previous example of wget, widely re-used by package management systems like ports/pkgsrc, and explain to me why HTTP should dictate its behavior based on the market concerns of browser vendors. I have no less than four httpds running at this moment in my office, embedded in my router and my printer, for example. I will grant that they generate crappy, nonconformant HTML. I understand browser vendors' concerns with defining a parsing model which understands HTML as used in the wild, which is why I haven't pushed back on how HTML 5 is being authored. But that logic simply does not apply to messaging. HTTP is *not* a standardization effort around implementation details within a component, its scope is limited to defining conformant messaging syntax between connectors. No evidence has been presented explaining why HTTP should be a browser-behavior-centric specification like HTML, and until that rationale is provided there is no basis for demanding that the spec author present evidence that every edge-case of nonconformant syntax has been accounted for, backed up by irrelevant references to what browsers do. -Eric
Received on Sunday, 3 October 2010 18:49:47 UTC