W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

RE: Suggestion for NEW Issue: Pipelining problems

From: Eric Lawrence <ericlaw@exchange.microsoft.com>
Date: Tue, 17 Jul 2007 09:06:22 -0700
To: Travis Snoozy <ai2097@users.sourceforge.net>
CC: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <8301DE7F96C0074C8DA98484623D7E51158C1F6F24@DF-MASTIFF-MSG.exchange.corp.microsoft.com>

<< Marking a message "HTTP/1.1" should do that >>

Of course it should, but clearly the practice of lumping multiple capabilities into a single capabilities identifier has not worked out in practice.

I don't think server developers are generally malicious, so I don't think it's likely that those NOT attempting to support pipelining would go out of their way to report that they support Pipelining when they've made no attempt to do so.

While you're right that there's nothing stopping a server from trying to support Pipelining, reporting it does, and having bugs in such implementation, ~that~ is a much more constrained problem than Opera and other clients face today.

I'm not sure how a certification process would help with the deployed servers problem.  If there were some way to make certification mandatory (seems unlikely) then you could prevent deployment of additional broken servers, but it will be MANY years before the existing base of broken servers will be retired.

Eric Lawrence
Program Manager
Internet Explorer
Want to view and tamper with HTTP(S) traffic?  Try Microsoft Fiddler
Install IE7 - http://install7.com

-----Original Message-----
From: Travis Snoozy [mailto:ai2097@users.sourceforge.net]
Sent: Tuesday, July 17, 2007 8:54 AM
To: Eric Lawrence
Cc: Yngve N. Pettersen (Developer Opera Software ASA); ietf-http-wg@w3.org
Subject: Re: Suggestion for NEW Issue: Pipelining problems

On Tue, 17 Jul 2007 08:31:14 -0700, Eric Lawrence
<ericlaw@exchange.microsoft.com> wrote:

> I think Yngve is primarily pointing out that a significant body of
> the deployed base of HTTP servers do not support pipelining.
> Unfortunately, there's no reliable method, a priori, to determine
> whether or not the remote server is going to handle pipelining
> correctly, or whether it will either crash or deliver incorrect
> results.
> I don't know that ambiguities or inaccuracies in the RFC are to
> blame-- I think the problem is that most servers never bothered to
> try to handle pipelining correctly.


> Proposed modifications I've seen to help reduce the need for client
> heuristics include:


Marking a message "HTTP/1.1" should do that -- clearly, it hasn't
stopped folks from doing an abysmal job at implementing this
and other features. Likewise, nothing prevents this exact same
problem from re-occurring, with badly-behaving servers claiming to
support pipelining via any new identification mechanism proposed[1].

Really, I think that the best solution for this (and many other
HTTP-related problems) is to have a certification process, and
(ideally) a reference implementation. For the server validation at
least, it could even be an automated service (like the W3C (X)HTML


[1] The suggestion does, however, open up the interesting notion of
modularizing HTTP -- which would be nifty, but probably something
more suited for a 2.0 revision.
Received on Tuesday, 17 July 2007 16:08:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC