- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 5 Jun 2014 11:10:20 -0500
- To: HTTP Working Group <ietf-http-wg@w3.org>
Recent threads have discussed how more limited servers, perhaps running on embedded devices, or resource constrained intermediaries, could use SETTINGS to reduce the decoding overhead both in terms of table size, and depending on the output of #485, potentially usage of huffman. However, even with this capability, these servers are still required to process requests up until the client has received and processed the SETTINGS frame. I understand that this is purposefully not a full negotiation due to the RTT cost. However, since there is also no form of flow-control on HEADER frames, a client can (and likely will) send as much as it can when the connection is initially created. Depending on the stickiness of traffic patterns (or more precisely lack thereof), this could be a significant volume of traffic. Should there perhaps be some cooperative limitation on the amount of request data that can be sent before receiving the first SETTINGS frame (i.e a temporary flow-control)? An alternative could be for an implementation to ignore the request content and use Retry-After in some scheme to force adoption of the SETTINGS values. However, it becomes guess-work on specifying the time amount. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 5 June 2014 16:10:48 UTC