RE: Making Implicit C-E work.

On May 15, 2014 9:42 PM, <K.Morgan@iaea.org> wrote:
>
> On Thursday,15 May 2014 12:53, Mark Nottingham wrote:
> > On 15 May 2014, at 11:48 am, Martin Thomson <martin.thomson@gmail.com>
wrote:
>
> >> I am down with Matthew's suggestion here to lift the MUST. Though I
note that there
>
> >> are cases where this places an intermediary between a rock and a hard
place in terms
>
> >> of conflicting requirements. Maybe we can note that an intermediary
/could/
>
> >> decompress and leave the normative text out of it.
>
> >
>
> > That makes sense to me…
>
>
>
> Let's be more clear.  That only makes sense _if_ you are assuming
acceptance of Roberto's proposed "uncompressed-*" headers solution.
Otherwise this doesn't solve any of the problems brought up by Matthew,
Julian, myself and others with respect to etag, no-transform, metadata
within the entity body, etc...
>

Nnnno... I think it resolves the issue I had, even without any extra
details. Right now a server is well within its rights to completely ignore
any and all Accept-* headers; it's not the best for interop, but it's legal
within the spec (406 might be better, but also not always great for
interop).

The "MUST decompress" effectively made gateways act as origins for certain
responses, but they didn't have a choice about how to deal with this
interop issue. By not saying anything we grant them the choice of
decompressing, or sending compressed, or 406ing.

If anything I'd probably appreciate something that warns H2 clients not to
rely on implicit a-e:gzip, because servers might treat implicit and
explicit headers differently.

I still definitely prefer not introducing implicit support in the first
place.

>
>
>
>
> On Tuesday,29 April 2014 22:29, Roberto Peon Wrote:
>
> > [SNIP]
>
> > Servers seeing an implicit gzip a-e and sending a compressed entity MAY
include an
>
> > additional header field, ":uncompressed-etag" …
>
> > [SNIP]
>
>
>
> I take issue with the MAY.  IMO, if the server wants to use implicit gzip
it MUST include the "uncompressed-*" header fields, if such a header would
have been sent with the corresponding entity with c-e: identity. Otherwise
it forces the intermediary into a position where it has to either 1)
decompress and break the metadata, or, 2) forward the response as-is and
possibly cause inter-op issues (on second thought, maybe this a desirable
feature for Roberto and others?).
>
>
>
>
>
> Finally, I also would like to see text added to Roberto's proposal about
how servers should deal with range requests with respect to implicit c-e
gzip.  As I've pointed out many times, the range n-m of a c-e gzip entity
is NOT equal to the range n-m of the entity's c-e identity encoding.
Example text:
>
>
>
> >>>
>
> If a server elects to service a range request, it MUST NOT use implicit
gzip content encoding.
>
> <<<
>
>
>
> As I pointed out earlier though, this opens up loop-holes for
intermediaries to work around implicit gzip...
>
>
>
> On Wednesday,14 May 2014 09:28, MORGAN, Keith Shearl wrote:
>
> > This introduces loop-holes for all of those intermediaries you're
trying to combat which strip a-e gzip.
>
> >
>
> > For example, an intermediary could...
>
> > + Strip a-e gzip and inject a range request for the entire content:
>
> >    "Accept-Encoding: identity"
>
> >    "Range: bytes=0-"
>
> > + Or, if the server is too smart for that, strip a-e gzip and inject a
multi-part range for the entire content:
>
> >    "Accept-Encoding: identity"
>
> >   "Range: bytes=0-0,1-"
>
> > + Or, if the server is really smart, strip a-e gzip and split the
request into two separate range requests for the entire content:
>
> >    "Accept-Encoding: identity"
>
> >    "Range: bytes=0-0"
>
> >    ...
>
> >    "Accept-Encoding: identity"
>
> >    "Range: bytes=1-"
>
> >
>
> > Of course the server could simply disable Range requests (i.e. always
send the full c-e gzip response - which is legal).
>
> > I would argue that this will also degrade the user experience as there
are more and more users browsing on spotty
>
> > networks (e.g. Safari doesn’t use range requests [1] and it drives me
crazy every time I’m loading a page and there
>
> > is a break in network connectivity on the subway, because then it has
to start all over).
>
> >
>
> > [1]
http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0112.html
>
>
>
>
>
> This email message is intended only for the use of the named recipient.
Information contained in this email message and its attachments may be
privileged, confidential and protected from disclosure. If you are not the
intended recipient, please do not read, copy, use or disclose this
communication to others. Also please notify the sender by replying to this
message and then delete it from your system.