Re: #445: Transfer-codings

Matthew Kerwin wrote:
> 
> But I have to respond to one particular type of comment that keeps
> coming up: "*well-constructed sites which compressed their
> resources.*"
> 
> That's a big value judgement on what constitutes good site design.
> Yes, in lots of cases it makes sense to compress your resources and
> have multiple representations, especially for static resources; but
> what about the sites that aren't like that? Why is it bad site design
> to have a big resource that can be accessed with ranges? If the
> answer is because doing so would require TE in order to have
> compression, then it's a tautology (TE is only needed by bad sites;
> those sites are bad because they need TE). If it's because caches
> don't handle that properly, then it's a chicken-and-egg problem. The
> only reasons I can think of for calling them bad are either circular,
> or "I don't like them." Is there a real reason?
> 
> Why should I make my web API use "?start=N&end=M" when I could use
> "Range: x-records=N-M" ?
> 

Agreed. Mnot's "get off my lawn" RFC seems to prefer a protocol-level
solution instead of attempting to standardize range requests as part of
the http scheme. IMO, accepting that resources have representations
leads us right back to transfer codings, unless range requests to large
files are deprecated as somehow being bad design, which anyone who's
had to use them (and found it to work) knows better than. Which still
doesn't solve the problems led to by deprecating T-E.

-Eric

Received on Tuesday, 15 April 2014 08:55:03 UTC