Re: Making Implicit C-E work.

On May 3, 2014 8:31 AM, "Roberto Peon" <grmocg@gmail.com> wrote:
>
>> - Matthew wrote: "[What about] last-modified? And, possibly, other
fields from Vary? There's more entity-specific metadata than just ETag."
>>
>
> The rule is simple ":uncomressed-foo" replaces "foo" if decompression is
done.
>

Ohh, is this a header pattern? As in, all headers that start with
":uncompressed-" (or whatever) get copied across at the gateway?

So you're effectively sending two complete sets of headers, and optimising
for the overlap.

I can live with this idea, as long as it's made really clear which header
is used by caches and origins for supporting conditionals and ranges in
which situations.

>>
>> - Matthew also wrote: "Cache-Control:no-transform explicitly forbids the
proxy from altering the representation. It's not allowed to decompress it."
>
> I've addressed this. It isn't altering the representation if it is
effectively transmitting both.
>

Yeah, I understand this now; you've theoretically transmitted the
uncompressed entity and all its headers, and the compressed one and all of
its. Two tiers of encoding. And because you can detect support for c-e, you
can choose to only use one or the other, if you want.

It's a pretty conceptually rich change; I'd imagine not a great deal of
code would change, but I think it needs a bit more thinking and discussion
to make sure we end up with something that works properly and doesn't hide
other problems.  Are people happy to invest time into something like this?