Re: Compressed requests

You break everything **only** if you send compressed data by default.
The server needs to understand it's receiving compressed data and behave
accordingly, this means the client has nothing to do with this capability
so it has nothing to check.

It's like me sending today valid JSON data to an end point that does not
support it ... it would be me being an idiot, I guess, and not the server
being broken or something :D

One thing for sure, I agree sending compressed data or even before the
ability to compress data in core via JS is what I am looking for,
everything else can be built on top, it should not be attached to a JSON
form behavior indeed.

Cheers



On Mon, Mar 3, 2014 at 11:57 AM, Robin Berjon <robin@w3.org> wrote:

> On 03/03/2014 19:21 , Andrea Giammarchi wrote:
>
>> Quickly my thoughts on this:
>> I believe there is no endpoint in the real world that is not capable of
>> inflating, or un-gzipping any content so I'd skip the "check the server"
>> part since you know who you are sending data to because this needs to be
>> stored or analyzed in there, accordingly the end point needs to know
>> what kind of data is receiving and since it supports already files, I
>> don't see concrete problems in supporting any sort of compressed binary
>> with a Content-Type that will be parsed after decompression.
>>
>
> The problem is not being able to support, the problem is being ready to
> support.
>
> What implementations do today is that they just mostly read off a buffer
> (if not STDIN) and parse that without caring about Content-Encoding. We
> absolutely can't start to change that without breaking everything.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>