Re: Compressed requests (was: Submitting forms as JSON)

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.


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

> Hi Andrea,
>
> On 25/02/2014 18:53 , Andrea Giammarchi wrote:
>
>> This is awesome!!!!
>>
>
> Glad you like it :)
>
>  The only thing I believe is missing is the ability
>> to specify a compression encoding as gzip or deflate in order to boost
>> up repeated properties name as well as base64 data.
>>
>
> It is true that for large requests it would be valuable for the browser to
> be able to apply compression. However I think that that requirement is
> orthogonal to the ability to transmit JSON -- it would be useful for other
> form encodings as well.
>
> I'm not sure how best to enable that though. In a perfect world the
> browser could just query the endpoint for support automatically, but we
> live in a world far, far away from that one. A MIME pseudo-parameter seems
> dirty at best; an attribute feels overkill. Any thoughts?
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>