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

Re: Making extensibility cheap

From: Daniel Sommermann <dcsommer@fb.com>
Date: Wed, 4 Jun 2014 10:06:44 -0400
Message-ID: <538F27F4.1010100@fb.com>
To: <ietf-http-wg@w3.org>
On 06/04/2014 12:26 AM, Matthew Kerwin wrote:
> If DATA compression was made an extension, there are two ways forward 
> that I can see:
> 1. Give hop-by-hop extensions the ability to modify existing frames 
> (add flags, maybe add fields, etc.) -- note that this pretty much 
> leaves DATA compression exactly where it is, but with different name 
> for the setting.
> 2. Mint an extension frame that looks almost exactly like DATA, but 
> includes the compression stuff. If this was a hop-by-hop extension I 
> think there'd be very little disruption to the current spec; however 
> it could also become an end-to-end frame. That idea has much more 
> far-reaching consequences (e.g. does it cross a semantics boundary to 
> move data outside of DATA frames? What do non-extension caching 
> proxies do? Etc.) and I've put no more thought into it than what I've 
> just written, but it's a possibility.

I think it would be nice to allow extensions to add flags to existing 
frames, but in the proposals there is no segmentation between "reserved 
for RFC" and "experimental" flags, so that could potentially lead to 
conflicts down the road. We may need to go with #2.

I'm still not sold on the usefulness of end-to-end frames. If the goal 
is to avoid unnecessary decompress/recompress in proxies for 
COMPRESSED_DATA frames on each hop, I think that could be avoided just 
as well with a hop-by-hop negotiated compression. If both sides of a 
proxy negotiate the same COMPRESSED_DATA extension, then the frame can 
be forwarded as-is, just as with the end-to-end extension.
Received on Wednesday, 4 June 2014 14:07:17 UTC

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