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

Hi Brian,

I've been thinking about HTTP compression schemes too, but IMO the barrier to entry for hop-by-hop is probably too high, as that's getting perilously close to HTTP 2.0, and if we're going to go that far, we might as well go the whole hog (a la SPDY, WAKA, etc.). Also, header compression only works well if you have many requests on a connection; IME we're not there yet.

Rather, I'm seeing this draft as a mechanism for backing away from the spiral of unfortunate behaviours that the browsers have to implement to interoperate with really broken sites. My site doesn't need convoluted Accept-* headers, nor does it need a painfully wordy User-Agent, but the browsers still send the because some other broken sites do require this. Likewise, my site doesn't need browsers to be careful about pipelining.

Also, there is more in the draft than just reducing request header sizes; while that might be the most beneficial case for you, I actually started the draft for the pconn-ip behaviour. 

Regards,

On 19/05/2011, at 12: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

--
Mark Nottingham   http://www.mnot.net/