406 Not Acceptable
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice may be performed automatically. However, this specification does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
I'm not sure that a 406 response correlates directly with URI-length, but if it is in fact just the length of the request that's causing it, see the Apache "core features" documentation, LimitRequestFieldsize and LimitRequestLine settings.
LimitRequestFieldSize can be used to reduce the maximum allowable size of any HTTP request header field to below the compiled-in DEFAULT_LIMIT_REQUEST_FIELDSIZE limit (8190 bytes default as-shipped from Apache).
LimitRequestLine can similarly be used to limit the size of the clients request line ("GET /file.type?query#fragment HTTP/1.1") to below the compiled-in DEFAULT_LIMIT_REQUEST_LINE limit (again, 8190 bytes in a default configuration).
Since both of these limits are well above 600 characters, I'm not sure that this is the root problem.
Look at the client requests and server responses using a headers checker such as the "Live HTTP Headers" add-on for Firefow/Mozilla browsers or similar, and verify both the 406 server response code and the lengths of the client request headers and request line. Once you're sure that it's the request lengths that are the actual problem (and not, for example, that the browser is requesting data in "chunks" and the server isn't configured to support partial-content requests -- see
HTTP/1.1 [w3.org] "Range" request header and 206-Partial Content response header for more info), then you can proceed to ask your host to increase the configured limit or limits.
Failing that, the vendor of the software generating these lengthy requests should be asked to strip all non-essential characters out of these requests -- for example, by shortening query parameter names and/or omitting unused parameters.
Aside from the request lengths and the Partial-Content requests noted above, also look at the Content-Type(s) (a.k.a. "MIME-types") being requested as compared to those that your server is prepared to serve, and any other discrepancies between what the third-party script is telling the client to request and what the server is configured to serve. (Check the HTTP Accept, HTTP Accept-Language, HTTP Accept-Encoding, and HTTP Accept-Charset request headers.)
If it turns out that it really is simply the length of the requests that is causing this problem, then your last-ditch option will be to shop for a new host which configures these limits at 50 to 100% above your current actual needs, in addition to meeting all other server feature and performance requirements.
Jim
