W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: repeated filename parameters, Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

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>
Message-Id: <20101003124841.31b4cabb.eric@bisonsystems.net>
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.

Received on Sunday, 3 October 2010 18:49:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC