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

Re: Comments on draft-ietf-httpbis-content-disp

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 1 Nov 2010 15:40:49 -0600
To: Ian Hickson <ian@hixie.ch>
Cc: Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>
Message-Id: <20101101154049.701290f8.eric@bisonsystems.net>
Ian Hickson wrote:
> 
> As someone who works for Google, I assure you that we are interested
> in seeing strict client-side conformance requirements, including
> those that describe required error handling, in the HTTP
> specification. We want our crawling infrastructure to interoperate
> with Web browsers, and currently to do so we have to spend
> significant resources reverse-engineering those browsers. It would be
> better for us, as well as fostering improved competition in our
> space, if the specification could just define all this in detail so
> we didn't have to reverse-engineer anything.
> 

OK, point taken.  But, the argument remains one of the appropriate
scope of HTTP.  There are radically different classes of user-agents
with radically different concerns.  Browsers (and googlebot, fine)
represent only one class of user-agent concerns.  The protocol can't be
tailored to the needs of any class of user-agent, but must remain
agnostic.  In REST, this is known as the layered-system constraint --
messaging between connectors is a separate concern from interpretation
of those messages by components -- and this architectural principle is
reflected in the design of HTTP (and has been, since long before said
constraint was identified, described, or recognized as desirable
through extensive peer review).

HTTP defines the semantics of messaging between connectors.  Where the
handling concerns of an error message vary from one class of user-agent
to another, is the components' interpretation of the status reported by
the connectors.  Thus, implementation details of components are not in-
scope to HTTP -- the protocol design either has to account for handling
by every conceivable class of user-agent, or draw a line at what meaning
the status codes intend to convey.  It is appropriate to draw this line,
rather than convert HTTP into a browser-specific protocol which
sacrifices readability by jobbing developers, while becoming oblivious
to the needs of other classes of user-agent by focusing on what's best
for the browser/search markets.

I'm not dismissive of your concerns, just saying they are not
appropriate to the scope of this protocol, which must also take into
consideration such diverse uses of HTTP as package-management systems
where the error *reporting* requirements are not the same as for
desktop browsers or even crawlers, even though the semantics of the
status codes are invariant across all user-agent classes.  Where there
are security concerns requiring particular handling by all user-agents,
I'm in favor of adopting solutions proven out in existing browsers.
What I'm opposed to, specifically, is basing the protocol on any single
class of component concerns, when its scope should be limited only to
the semantics of messaging between connectors.

There are valid reasons for, and apparently the desire to, create an
interoperability specification based on browsers.  But I see no reason
why such work would or should change how HTTP is parsed, or its
semantics defined.  What a component does with messages is up to the
component, not the protocol.  Which is why I see these requirements as
being out-of-scope to HTTP.  I'm not joking at all when I suggest a w3c
HOM activity devoted to documenting interoperable implementation details
for any class of user-agent for which they're deemed relevant.  I just
can't imagine any such document applying to *all* classes of user-agent,
which is why I'm opposed to expanding the scope of HTTPbis to attempt
just that, which is exactly the slope we start slipping down by speccing
non-MIME-compliant C-D syntax based on, at best, a 1% use-case.

-Eric
Received on Monday, 1 November 2010 21:41:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT