On Mar 12, 2012, at March 12, 20121:23 PM, Dick Hardt wrote:
>
> On Mar 12, 2012, at 12:57 PM, Mikeal Rogers wrote:
>
>> Supporting it means defaulting to using an accept encoding header and then
>> decompressing the response automatically. We cannot assume this is always
>> what you want.
>
> agreed
>
>>
>> First of all, this increases the amount of CPU each process will use. Many
>> servers won't want to sacrifice CPU for bandwidth.
>
> Not a choice for client if server is sending gzip. eg. stack exchange APIs
> all send gzipped responses. My applications here tend to be 'client' side as
> well.
If a server is sending you gzipped responses and you are not sending an
accept-encoding header for gzip then the server is breaking the HTTP spec.
>
>>
>> Second, with the pipe/stream system in request you may actually want to get
>> a response gzipped and then store it that way on disc so you'd want to opt
>> out of decompression.
>
> agreed as above
>
>>
>> Defaulting to one behavior automatically makes too many assumptions. Most
>> people use a higher level library anyway, let them sort out what they want
>> their behavior and API to look like and keep this out of core. Being able to
>> do something doesn't mean we *should* do it :)
>
> Already defaulting to not doing decompression. :)
>
> I recently wrote a utility to grab data from some stack exchange sites. After
> spending an hour trying to decompress the buffers coming in (first time
> trying to work with buffers), I gave up and just did an exec of curl.
>
> Being able to set a flag in https.request similar to setEncoding('utf8')
> would be useful. Would not alter existing code and would make it much easier
> to.
>
> btw: I find https.request to be the right level of abstraction for my
> application. I don't require much wrapper code for my applications. The only
> thing that I would need would be one that did decompression, and I could not
> find one for that, and the samples out there did not show how to get the full
> response in one chunk.
You say it's the right level of abstraction but you have all of this code on
top of it which you think belongs in that layer of abstraction. We have a good
history of this functionality being written in to higher order HTTP clients and
node's vision of a slim core means that everyone needs to get comfortable using
third party dependencies.
>
> -- Dick
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
