Re: Support for gzip at the server #424

On 15/03/2014 9:58 a.m., Zhong Yu wrote:
> On Fri, Mar 14, 2014 at 1:21 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> Compressed uploads isn't a new feature, but it has poor interop.
>> This would fix the interop problem.
> 
> RFC2616: All HTTP/1.1 applications MUST be able to receive and decode
> the "chunked" transfer-coding
> 
> I was fooled by the stern language and implemented it in my server -
> apparently for nothing :(

That is receive not send.
The biggest problem here is HTTP/1.0 clients not being able to receive
chunked. So it cannot be relied on by any 1.x clients on first request
(which PUT/POST usually have to be).

The only way to get reliable transfer other tan with content-length is
to send Expect:100-continue and get a working result to that.


AYJ

> 
>>
>> On Mar 14, 2014 10:54 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>>
>>> On 14 March 2014 10:42, Roberto Peon <grmocg@gmail.com> wrote:
>>>> imho, the simple solution is to mandate the presence of a header that
>>>> indicates the uncompressed content-length when sending compressed data
>>>> on
>>>> http/2. This is generically useful in many applications in both
>>>> directions.
>>>
>>> Not that it wouldn't work, but that sounds a little too much like a
>>> new feature to me.
>

Received on Friday, 14 March 2014 21:50:50 UTC