- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 04 Feb 2013 18:29:38 +0000
- To: William Chan (ιζΊζ) <willchan@chromium.org>
- cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=ISO-8859-1 -------- In message <CAA4WUYiBJrLjM0-vurFOuJfUaabXtK=W8N5z28yshSfrvD9crg@mail.gmail.com> , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes: >But let's return to the premise. Do you believe it's better to rely on >these client fingerprinting methods to implement prioritization, >rather than providing more explicit signals in the protocol itself? I belive that the client is welcome to suggest what kind of priority it would like to have, and that in the end, the other end is going to do whatever it likes, which may be to honor the clients desires, but most often isn't. >>> So what does the groups buy you, for all the complexity they add ? >>> >>> As far as I can tell: Nothing. > >I'm sorry I didn't address this in the first email. I confess I >thought it was obvious. Grouping lets you do relative prioritization >within a group, as opposed to across the entire session. I understood that, my question pertains to reality: What do you get in the _real_ world scenario ? Likely a DoS amplification if the proxy honors the client's priority desires... I'm fine with the client communicating a desired priority, I'm not fine with 50 pages of standards-verbiage about what the other end should do about it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 4 February 2013 18:30:12 UTC