RE: NEW ISSUE: Use of "Client" in 14.4

William A. Rowe, Jr. said:
> Travis Snoozy (Volt) wrote:
>
> > ... but that is then inconsiderate of anyone who is reading the spec
> > from scratch, is it not? And since this *does* center around a MUST-
> > level requirement, I for one think it's very important to fix. Even
> > though the likely intent is clear to anyone who thinks about it long
> > enough, what the spec *says* will cause clients that do the sane thing
> > to be non-conformant.
>
> I read a MUST-NOT, not a MUST.

You read correctly (well, aside from the hyphen, but that's splitting hairs
:). I'm expressing the MUST NOT requirement in the positive sense (as a
MUST) -- if I've made a semantic change in this transformation, please point
it out.

> If there is no way to infer the user-agent's preference, do not present an
> Accept-Language header.

The spec doesn't say "infer" or "user-agent"; it says that an -option has to
be made available- to the -user- (by [all] client[s]).

An example to demonstrate the problem:

Fred runs a browser (user-agent). Fred has configured his browser for the
Yiddish language. Thus configured, the browser sends a request with an
Accept-Language header to Fred's border proxy. Everyone is happy so far.

Now, what happens? Fred's border proxy is a client; as such, it MUST make a
linguistic option available to the user before giving an Accept-Language
header in the request (which it's forwarding). However, in order to do that,
Fred's proxy has to communicate back with Fred somehow. Thus, Fred's poor
proxy is left in the dilemma of either having to discard the Accept-Language
header (which means Fred isn't likely to get Yiddish), or send a page back
to Fred ("Do you really want Yiddish?"), or *violate the spec* and pass the
Accept-Language header to the origin server *without making a language
option available to Fred*.

Why should the proxy have to make a language option available to Fred? The
user-agent already did that. The proxy has no business doing it again, and
it just gets in the way. The sane thing to do is to just pass the Accept-
Language header along -- and that's why I think the wording should be
changed, so this behavior is allowed.

Now, all that said, the proposed wording could certainly be phrased better -
- most notably, because it should prohibit the proxy from sticking in
arbitrary Accept-Language headers on behalf of an unwitting user. But the
pass-through case should most certainly be permitted.

> This statement applies, in equal part, to an endpoint client agent as well
> as any middle layer agent.

Yep. That's the problem -- middle-layer agents don't have a way to make the
option available to the user, nor do they have a way to verify that the
option was -actually- made available to the user from whatever upstream HTTP
application gave them the message. So, middle-layer agents either have to
strip the Accept-Language header, or do something silly to try and get the
user to explicitly pick a language. That's why the requirement needs to be
narrowed down to "user agents" instead of "clients."

> > On the other hand, I don't think that anyone really cares if their
> > client/server is "HTTP/1.1 conformant" at this point.
>
> I would choose words more wisely when emailing from a work account.

"The opinions expressed in this E-mail are that of the author, and do not
constitute any official position held by the author's employers or
affiliates..."

I'd like to think that choosing wise words is a skill that is independent of which keyboard I'm at. That said, I'd rather be wrong and corrected than right and silent. :)

> Developers at Apache, Mozilla, certainly even at Microsoft do pay close
> attention to the specification.

I never intended to imply that they didn't. What I said was that I do not
think anyone really cares if their client/server is "HTTP/1.1 conformant".
In straightforward terms: is it preferable to have a browser that works as
expected, or a browser that's HTTP/1.1 compliant (assuming mutual
exclusion)? A cache? A server? From the discussion so far, folks seem very
much more interested in having things that *work*, even though they aren't
*technically to spec*.

I, myself, am interested in pointing out and fixing warts in the spec such
that literal adherence leads to the creation of something that works as
expected. Strict conformance and (inter)operability should not be mutually
exclusive; likewise, implementers should be rewarded for following
directions to the T (i.e., not interpreting *anything*), not punished by
being broken-as-specified because they *didn't* interpret things. The spec-
writer is the one who should know best, IMO -- if the spec says jump off a
bridge, do it (and figure that the spec picked a low one with deep water
under it).

An excellent example provides itself, here:

> What they choose to do from that point forward is their own foolishness.
>
> The risk is that conformant++ behavior often becomes --conformant in
> actual practice, witness the attempt to be more forgiving of spaces
> between header fields and the separating colon of header strings, and the
> resulting HTTP request spoofing vulnerabilities between varying vendor
> agent implementations.

I feel like there's a contradiction. Earlier, it seemed to me like the
implication was to interpret the spec more loosely ("If there is no way to
infer the user-agent's preference, do not present an Accept-Language
header"), and do the right thing (violating the spec). Now, "conformant++"
(violating the spec) is a Bad Thing. This appears to be a double-standard;
am I missing something?


Thanks,

-- Travis

Received on Thursday, 4 January 2007 23:34:23 UTC