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 02:59:36 -0600
To: Roberto Peon <grmocg@gmail.com>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <20140415025936.58ee51f6a12185e88d3ac1ba@bisonsystems.net>
Roberto Peon wrote:
> I wouldn't mind fixing range-requests, but I don't believe that range
> requests make a whole lot of sense for dynamic objects anyway.
> I'm more than happy to have my ignorance corrected :)

Some large dynamic objects persist long enough between changes for range
requests to be a big win, particularly for clients with intermittent
connectivity, particularly when compression is possible. I'm not at
liberty to discuss a project I was consulting architect on, which wasn't
as big as IAEA anyway so I'm sure it also pales in comparison to the
Web-browsing use case generally deferred to here.

But, the most painful bit of code I've ever written implemented T-E
compression of range requests. As Helge Hess mentioned elsewhere, I
don't get how to manage the Etag if T-E is gone and conneg is in play.
Which it is, if the large dynamic object is C-E compressed text because
the user-agent won't display *.html.gz served as application/gzip and
no support exists for displaying this served as application/html+gzip,
which would be the "right way" to do things IMO.

Resources having representations is a fact of life even if T-E is
removed and gzip mandated. Even if I didn't have personal experience
with this, I would extend the benefit of the doubt to the IAEA guys (as
I don't know the specifics of their use-case) before declaring it
nonsensical... some of us have found applications for range requests
which don't begin to resemble pre-compressed image or video content.

Received on Tuesday, 15 April 2014 08:59:58 UTC

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