2 min read
Modern home gateways and Wifi routers have a lot of advanced functionality that do more than simply push packets. Devices that look directly at application layer traffic may do so for a number of reasons:
And others. Since there is a level of processing happening at the application layer, it’s important to test that the gateway can handle unusual or edge-case data that may end up going through this processing.
Other than DNS, HTTP (and HTTPS) is probably the most common application layer protocol to be affected by the performance of an application aware gateway. One of the ways a gateway can trip up this process is an inability to handle large numbers of http headers that may be in use by some advanced applications.
There are many resources that explain the limitations http servers place on the raw size of http headers. In Apache, for example the default limit is 8KB. In IIS, it’s 16K. This is a server side setting that can be adjusted, and servers will return a “413 - Entity Too Large” error if the message is exceeded.
But beyond the limits of the http servers themselves, an application aware gateway may have its own processing limitations on the http header. These limitations may be on the size of the header, but also on the number of fields passed. An application aware gateway may processes these headers as part of its advanced functions, and too many headers can create a choke point. If the processing fails at this level, the user’s browser will never get an error, and will hang waiting for the server’s response.
Large numbers of http headers sent by CDRouter
CDRouter 10.5 introduced several new test cases to cover these scenarios. With tests for HTTP 1.0, 1.1, HTTP2, and HTTPS, you can push the limits of your device under test on the number of http headers it can successfully process when passing a user initiated GET message from the LAN to a WAN side http server. With a testvar called httpMaxHeaderCount (that defaults to 200), you can increase or decrease the number of headers CDRouter generates to discover what limitations your DUT may have.
While this may seem like an edge case, it’s one of the pieces of “tricky behavior” often missed during the testing process that ends up in very real (and poor) experiences for the end user