W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #445: Transfer-codings

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 15 Apr 2014 03:05:07 -0600
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
Message-Id: <20140415030507.e3b1e3ca4542bfcd3db624a6@bisonsystems.net>
Martin Thomson wrote:
> >
> > This sounds like a snark, but it's not: what is a better
> > alternative here? C-E is an alternative, but it has deficiencies.
> I think that - on balance - Content-Encoding is a better alternative.

Well, that's one opinion. Another would be to find an alternative that
isn't horrible protocol design exacerbating a known problem with HTTP
1.1, regardless of "how late in the process" this issue has come up.

> > My goal with this proposal was partly to support compression on
> > range requests, and partly to de-emphasise the current practice of
> > on-the-fly C-E. To that end, I don't know of any alternatives at
> > all.
> I don't want to sound too negative about range requests, but it may be
> that many of the cases that depend on range requests would be better
> served by giving the things that you are pushing across the network
> actual names, then using content encoding.

Even if it were feasible in a use-case I encountered, sharding the files
and allocating URIs to the bits and pieces solves your problem, but
leaves me writing a whole bunch of project-specific code (client and
server!) to split and re-combine what my customer (rightly) sees as one
file, when HTTP 1.1 has exactly the range-request facility I need at the
protocol layer to support remote workers with spotty connections in
Timbuktu or wherever.

Even if this were feasible, I'd rather not maintain non-portable code
for a feature HTTP2 removed before I was done using it. Client would
rather not pay me to re-code their application just so they can upgrade
to HTTP2. I'd rather not touch an application that's been working for
years on HTTP 1.1 w/ range requests and T-E.

OTOH, modifying an httpd to properly handle range-requests is something
I can file a bug against and eventually not have to worry about
maintaining. Meanwhile, I can use my fix on multiple projects because
it's part of the protocol, not the application. Once I've figured out
how a tool works, I'm likely to use it again if I find it appropriate,
so I'd prefer to keep it in the toolbox instead of missing it down the
road. YMMV.

Received on Tuesday, 15 April 2014 09:05:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC