Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt

For those that are new to such concept, or can't make heads or tails out 
of "the content", I explained the basics of the code here:

http://icyspherical.blogspot.com/2011/05/unix-in-xml.html

And, why we do not put the spin on hypermedia: 
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0240.html

We did our homework (for Science of the Letters).

On 05/18/2011 10:45 PM, Dzonatas Sol wrote:
> #!twitter.com/Dzonatas_Sol/status/71018131946082304
>
> Proven standard and extensible with channel persist objects; it works 
> in less than #140.
>
> On 05/18/2011 07:03 PM, Brian Pane wrote:
>> Reading through the browser hints draft,
>> http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
>> first reaction is that it specifies a really arbitrary subset of
>> request headers that clients can be advised to stop sending.
>>
>> While there's definitely some benefit to be gained by addressing
>> special cases like this, I think a general-case solution would be
>> preferable: a hop-by-hop response header that tells the client that
>> the server (or intermediary) supports compressed headers.  This would
>> require the definition of a compressed header standard, of course.
>>
>> Of the specific headers covered in the draft, many have the same
>> values on every request: Accept, Accept-Charset, User-Agent.  Header
>> compression would be very effective for these and for some other
>> common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
>> addition, Cookie and Referrer would benefit from compression in a lot
>> of common cases.
>>
>> -Brian
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant