Re: #445: Transfer-codings

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.

-Eric

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